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SUMMARY  PAGE 


THE  PROBLEM 

To  determine  the  degree  to  which  the  design  of  the  multifunction  switching 
system  employed  for  system  control  and  data  entry  in  the  ISPE  submarine 
sonar  system  allowed  rapid,  flexible,  and  error-free  operation  of  the  system. 


FINDINGS 

The  analysis  was  confined  to  controls  associated  with  displays  available 
in  the  search  and  class-loc  configurations.  All  functions  desired  by  the 
operators  were  readily  accessible.  Analysis  of  errors  revealed  that  it  is 
very  easy  to  misfile  information  or  assign  resources  to  the  wrong  contact. 

There  were  a  number  of  errors  traceable  to  control  labels  that  were  not  as 
informative  as  they  might  be,  and  one  instance  in  which  the  same  label  was 
used  for  controls  having  different  functions.  There  were  three  instances 
in  which  limitation  of  access  to  controls  when  in  the  hooked  mode  appeared 
to  be  counterproductive.  It  was  suggested  that  the  sonar  threat  acknowledgement 
functions  be  made  more  flexible.  The  overall  operability  of  those  parts  of 
the  control  structure  tested  was  judged  to  be  very  good,  and  operation  of  the 
system  appeared  to  be  very  easy  for  men  familiar  with  the  principles  of  sonar 
to  learn. 


APPLICATION 

The  report  recommends  ways  of  correcting  deficiencies  noted,  and  the 
identification  of  problem  areas  will  aid  designers  of  future  systems. 
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ABSTRACT 


Eight  experienced  FBM  sonar  operators  participated  in  an  evaluation  of 
the  "operability"  of  the  multifunction  switching  system  employed  for  system 
control  and  data  entry  in  the  ISPE  submarine  sonar  system. .  Operability  was 
operationally  defined  in  terms  of  the  availability  of  controls  for  desired 
functions  and  the  number  and  kinds  of  errors  associated  with  control  usage. 

The  sonarmen  were  individually  instructed  in  system  operation  for  three  days 
and  then  participated  in  two  days  of  testing  inv/which  they  employed  the 
simulated  system  in  two  multi-contact  scenarios. 

The  analysis  was  confined  to  controls  associated  with  displays  available 
in  the  search  and  class- loc  configurations.  All  functions  desired  by  the 
operators  were  readily  accessible.  Analysis  of  errors  revealed  that  it  is 
very  easy  to  misfile  information  or  assign  resources  to  the  wrong  contact. 

There  were  a  number  of  errors  traceable  to  control  labels  that  were  not  as 
informative  as  they  might  be,  and  one  instance  in  which  the  same  label  was 
used  for  controls  having  different  functions.  There  were  three  instances 
in  which  limitation  of  access  to  controls  when  in  the  hooked  mode  appeared 
to  be  counterproductive.  It  was  suggested  that  the  sonar  threat  acknowledgement 
functions  be  made  more  flexible. 

The  overall  operability  of  these  parts  of  the  control  structure  tested 
was  judged  to  be  very  good.  Operation  of  the  system  appeared  to  be  very 
easy  for  men  familiar  with  the  principles  of  sonar  to  learn. 


OPERABILITY  EVALUATION  OF  THE  ISPE  CONTROL  STRUCTURE 


The  acronym  ISPE  stands  for 
Improved  Sonar  Processing  Equip¬ 
ment,  the  developmental  name  for 
a  system  intended  to  upgrade  the 
sonar  capabilities  of  616  and  640 
class  fleet  ballistic  submarines 
in  service  in  the  1980-early  1990 
time  frame.  The  first  units  will 

join  the  fleet  in  1982  as  the 
1 

AN/BQQ-8.  The  system  provides 
centralized  digital  processing  of 
signals  taken  from  currently 
installed  sonar  arrays ,  the 
AN/BQR-7,  the  AN/BQR-21,  and  the 
AN/BQR-15 ,  thus  simplifying  the 
problem  of  retrofitting.  In 
place  of  the  collection  of  ded¬ 
icated  display  units  associated 
with  the  current  signal  processors, 
displays  and  system  control  are 
accomplished  by  means  of  three 
general-purpose  consoles  analogous 
to  those  used  in  the  AN/BQQ-5  and 
6  sonars.  In  addition  to  improved 
signal  processing,  ISPE  incorpor¬ 
ates  several  new  features  such  as 
automatic  motion  analysis  for  all 
contacts.  These  new  features, 
combined  with  the  desire  to 
exploit  the  flexibility  afforded 
by  all-digital  signal  processing, 
have  resulted  in  a  system  that  is 
both  more  capable  and  considerably 
more  complicated  than  the  combin¬ 
ation  of  equipment  it  replaces. 

The  operator  interface  in  ISPE 
consists  of  three  identical 
improved  sonar  operator  display 
(ISOD)  consoles  in  the  sonar 
shack  and  a  single  improved 
commanding  officer  display  (ICOD) 
located  in  the  control  room. 

The  ISODs  are  general-purpose 
units  having  two  vertically 
arrayed  cathode  ray  tube  (CRT) 
displays  and  associated  controls. 


The  majority  of  operator  actions  are 
performed  by  means  of  a  multifunction 
switching  system  (MFS) ,  which  takes 
the  form  of  a  row  of  ten  push  buttons 
(termed  variable  action  buttons  or 
VABs)  below  each  of  the  CRTs.  A 
label  describing  the  current  action 
of  each  VAB  is  written  in  the  function 
label  field  at  the  bottom  of  each 
display.  Additional  ISOD  controls 
are  mounted  on  the  console's  desk¬ 
top  panel.  These  consist  of  a  small 
number  of  dedicated  switches,  termed 
fixed  action  buttons  (FABs) ,  a  key 
pad  for  numeric  entry,  and  two  cursor 
controls;  a  stiff  stick  for  the 
vertical  and  horizontal  data  reading 
cursors  and  a  set  of  four  directional 
buttons  for  the  index  cursor,  which 
is  used  to  select  items  from  displayed 
menus.  The  ICOD  has  one  CRT  and 
associated  controls.  It  is  a 
functioning  operator  console 
(although  system  software  restricts 
ICOD  access  to  some  functions) 
instead  of  the  usual  simple  repeater. 

In  June  of  1978,  the  Naval 
Submarine  Medical  Research  Laboratory 
was  requested  by  OPNAV  to  conduct 
an  independent  evaluation  of  the 
operability  of  the  ISPE  system. 

Such  an  evaluation  falls  naturally 
into  two  parts:  analysis  of  displays, 
which  consititute  the  systems ' 
output  (Kinney,  et  al,  1980) ,  and 
analysis  of  the  controls  by  which  the 
system  is  configured  and  operated. 

A  majority  of  the  control 
functions  in  ISPE  are  implemented 
by  means  of  the  multifunction 
switching  system.  The  AN/BQQ-5 
and  6  submarine  sonar  systems  employ 
a  MFS  system  that  is  conceptually 
similar,  although  implemented  in  a 
somewhat  different  fashion.  It  was 
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thought  that  operators  has  exper-r 
ienced  difficulty  in  learning 
and  operating  that  system.  Thus 
OPNAV  was  specifically  concerned 
with  the  operability  of  the  MFS 
system  employed  by  ISPE.  The 
investigation  reported  here  was 
undertaken  in  response  to  this 
concern . 

The  defining  feature  of  a 
multi -function  switching  system 
is  that  a  small  number  of  -physical 
input  devices  (e.g.  push  buttons) 
are  used  to  control  a  larger 
number  of  functions.  This 
results  in  a  considerable  saving 
of  control  panel  space  and  may 
be  the  only  practical  way  to 
manage  a  complex  system  where 
literally  hundreds  of  control 
actions  are  required. 

An  obvious  but  absolutely 
critical  consequence  of  the 
raany-to-one  mapping  of  functions 
onto  controls  is  that  not  all 
functions  are  accessible  at  any 
one  time.  What  is  accessible  may 
be  controlled  manually,  by  a 
separate  selector,  or  it  may 
change  automatically  with  different 
options  succeeding  one  another  as 
controls  are  activated.  In  the 
ISPE  system,  control  functions  are 
grouped  to  support  tasks  associated 
with  the  type  of  information  being 
presented  on  particular  displays. 

The  system  couples  manual  selection 
of  displays  with  automatic  succession 
of  controls  for  functions  related 
to  that  display. 

One  important  consequence  of 
automatic  succession  is  that  the 
order  in  which  functions  become 
accessible  imposes  an  order  of 
activation.  In  many  cases,  this 
is  appropriate  and  beneficial 
because  it  precludes  out -of - 
sequence  activation.  However, 
many  controls  are  not  activated 
in  pre -determined  sequences,  but  in 


response  to  the  situation  with 
which  the  operator  is  dealing. 

When  automatic  sequencing  is 
employed,  the  designer  must 
insure  that  it  does  not  place  a 
control  out  of  reach  at  a  critical 
moment.  Thus  the  simple  availa¬ 
bility  of  desired  controls  is  a 
major  determinant  of  system 
operability. 

The  evaluation  reported  here 
concentrated  on  two  aspects  of 
the  implementation  of  the  ISPE 
multifunction  switching  system. 

The  first  of  these  was  the  simple 
availability  of  the  desired 
functions:  that  is,  would  the 
control  structure  allow  a  knowledge¬ 
able  sonarman  to  prosecute  a 
contact  in  a  simple  and  straight¬ 
forward  manner?  The  second  focus 
of  the  evaluation  was  to  determine 
which  elements  of  the  control 
structure  were  awkwardly  implemented 
or  likely  to  result  in  operator 
error . 

Approach 

It  was  decided  to  test  the 
operability  of  the  ISPE  control 
structure  by  means  of  a  simulation. 
Experienced  sonarmen  were  to  use 
the  simulated  system  as  best  they 
could  to  prosecute  a  number  of 
contacts  in  a  fairly  complex 
situation.  It  was  felt  that  their 
comments  and  the  problems  they 
experienced  in  the  simulation 
would  be  the  best  indicators  of 
potential  problems  to  be  encountered 
by  later  users  of  the  actual  system. 

Since  a  functioning  ISOD  was  not 
available,  and  the  dynamic  simula¬ 
tion  of  sonar  data  would,  in  any 
case,  have  been  prohibitively 
expensive,  a  very  limited  simulation 
was  used  in  this  study.  A 
computer  program  developed  by  NUSC, 
New  London,  simulated  the  succession 
of  available  controls.  Displays 


were  simulated  by  photographic 
reproduction  of  the  line  drawings 
presented  in  the  Functional 
Operational  Design  (FOD)  documents. 

Two  multi-contact  scenarios  were 
developed  and  read  to  the  operators 
in  a  step-by-step  fashion.  Operators 
were  told  of  various  events  visible 
on  the  displays  but  otherwise  no 
attempt  was  made  to  simulate  sonar 
data.  Although  hardly  lifelike, 
this  form  of  simulation  has  distinct 
advantages.  Problems  in  interpreting 
and  manipulating  the  control  structure 
are  not  masked  by  other  problems 
which  might  overshadow  them  in  an 
operational  evaluation.  That  is,  the 
hardware  is  assumed  to  function 
properly  and  the  displays  are 
always  easy  to  read.  The  operator 
is  free  to  concentrate  on  a  single 
question:  Will  this  system  let  me 
respond  as  I  think  this  situation 
demands? 

Materials 

The  major  piece  of  equipment 
used  in  the  evaluations  was  a 
Magnavox  Orion  60  plasma  display 
terminal.  This  is  a  desk -top  unit 
with  a  conventional  keyboard  and  an 
8.5  x  8.5  inch  display  surface.  The 
display  is  of  the  dot-matrix  type 
and  is  thin  and  transparent,  which 
allows  graphics,  in  the  form  of 
35  mm  slides,  to  be  superimposed  by 
means  of  a  projection  system  behind 
the  screen.  Standard  alpha-numeric 
characters  are  formed  from  a  7  x  9 
dot  matrix  and  are  approximately 
3.8  mm  tall.  The  display  provides 
32  lines  of  64  characters.  The 
characters  are  orange:  an  orange 
filter  was  used  to  match  the  color 
of  projected  slides  to  that  of  the 
alpha-numerics.  The  Orion  60  has  a 
"touch  panel"  feature.  Subjects 
could  thus  select  a  control  by 
simply  touching  the  appropriate 
label  on  the  screen ,  or  by  pushing 
the  associated  key  on  the  keyboard. 


The  ISPE  control  structure  was 
simulated  by  means  of  the  NUSC 
"Button  Tree"  program.  This  program 
writes  the  VAB  labels  associated 
with  each  display.  When  a  control 
is  selected,  the  labels  are  re¬ 
written  to  reflect  the  options  that 
become  available  upon  activation  of 
that  control.  The  program  also 
gives  those  error  cues  the  system 
would  generate  when  an  illegal 
operation  is  attempted,  although  it 
does  not  provide  unsolicited  cues  to 
the  operator.  The  VAB  labels 
provided  by  this  program  were 
shortened  from  a  maximum  of  8 
characters  to  a  maximum  of  5  so 
that  all  ten  VABs  could  be  printed 
side  by  side  on  the  face  of  the 
display  screen  used  for  the 
simulation^.  VAB  labels  for  the 
upper  CRT  were  written  at  the  top 
of. the  Magnavox  screen  and  those 
for  the  lower  CRT  at  the  bottom. 

The  NUSC  program  also  simulates  the 
actions  of  the  set  of  fixed  action 
buttons  (FABs) .  The  last  selected 
FAB  was  written  against  the  left 
edge  of  the  display  just  below  the 
upper  row  of  VAB  labels.  The 
"enter"  and  "sonar  threat"  FABs 
were  produced  with  a  line  of  Xs  to 
indicate  illumination  of  the  switch. 
In  order  to  minimize  display  re¬ 
write  time,  the  blanking  of  VABs 
when  a  numeric  entry  is  pending 
was  eliminated.  In  addition  to 
the  VAB  and  FAB  labels,  a  hooked  - 
not  hooked  indication  was  added 
to  the  display  for  the  convenience 
of  the  operator. 

The  "Button  Tree"  program  was 
executed  on  the  UNIVAC  1108  computer 
at  NUSC,  New  London.  The  display 
terminal  was  connected  with  the 
NUSC  computer  over  a  300  baud 
telephone  link.  Rewriting  the 
display  required  approximately  one 
minute,  sometimes  much  longer  if  the 
time  sharing  load  on  the  computer 
was  heavy. 
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Figure  1 


Schematic  of  the  display  as  it  appeared  to  the  subject.  Current  YAB  labels 
for  the  upper  and  lower  CRTs  are  represented  by  the  rows  of  rectangles  at 
the  top  and  bottom  of  the  screen.  Activated  FABs  were  written  below  the  upper 
row  of  VABs.  The  small  rectangles  at  the  left  edge  of  the  screen  contain 
(from  top  to  bottom):  the  hookedniot  hooked  flag,  a  count  of  the  control 
actions  to  date,  and  a  marker  indicating  whether  the  drawing  displayed 
represents  the  upper  or  the  lower  CRT  (the  Broad  Band  Search  display  is  shown) 


The  display  as  it  appeared  to 
the  subject  is  shown  schematically 
in  Figure  1  (facing) .  The  rows 
of  squares  at  the  top  and  bottom 
represent  VAB  labels;  the  two 
squares  below  the  top  row  of  VABs 
(on  the  left)  represent  currently 
active  FABs.  A  projected  line 
drawing  of  the  broad -band  search 
display  is  drawn  in  thicker  lines. 

The  three  small  boxes  at  the  left 
(beneath  the  FABs)  represent  (from 
top  to  bottom)  the  hooked -not  hooked 
flag ,  a  number  showing  the  count  of 
control  actions  so  far  completed,  and 
the  "upper -lower "  marker  (see  below) . 

The  ISPE  displays  were  simulated 
by  35  mm  slides  of  line  drawings  of 
the  displays  presented  in  the  FOD. 
These  were  rear -projected  onto  the 
face  of  the  computer  terminal  by  a 
Kodak  Carousel  slide  projector  which 
was  also  controlled  by  the  program. 
Since  only  one  slide,  representing 
one  of  the  two  displays  that  was 
"visible"  to  the  operator  at  a 
particular  moment,  could  be  displayed, 
the  program  selected  that  slide 
associated  with  the  last  activated 
VAB,  A  marker  appeared  on  the 
screen  indicating  whether  the  slide 
being  shown  represented  the  "upper" 
or  "lower"  display.  By  touching 
this  marker,  the  subject  could 
change  the  slide  displayed  to  that 
of  the  other  display  screen. 

No  attempt  was  made  to  simulate 
the  sonar  data  pictorially. 

Instead,  the  subject  was  told  what 
was  being  displayed,  e.g.,  "you  have 
a  new  trace  at  070°  on  the  left 
data  field." 

Two  multi -contact  scenarios 
(presented  in  Appendix  A)  were 
worked  out  in  detail  for  use  in  the 
operability  evaluations.  These 
were  designed  to  provide  a  large 
variety  of  sonar  events  with  which 
to  test  the  flexibility  of  response 
allowed  by  the  control  structure. 


The  scenarios  were  modeled  after 
the  TRACOR  "No-Fault"  and  "Decision- 
Making"  scenarios  developed  by 
J.  L.  Bryant  (1979a,  1979b),  but 
were  more  complicated  in  that  they 
incorporated  maneuvers  by  own 
ship  and  several  of  the  contacts. 

The  detection  ranges  and  contact 
characteristics  were  realistic ,  but 
no  attempt  was  made  to  closely 
model  the  expected  physical 
performance  of  the  ISPE  system.  A 
further  note  of  realism  was  injected 
by  having  own  ship  manuever  so  as  to 
avoid  coming  within  counterdetection 
range  of  the  threat  contact  (which 
was  never  allowed  close  enough  to 
be  detected  on  broad-band) . 

The  scenario  events  were 
translated  into  a  list  of  display 
indications .  Two  versions  of  each 
scenario  were  prepared,  one  listing 
display  indications  of  the  displays 
of  the  search  operator  console  and 
the  other  listing  events  on  the 
class-loc  console.  No  attempt  was 
made  to  test  the  adequacy  of 
controls  used  only  or  primarily  by 
the  supervisor.  It  was  felt  that 
operability  of  the  supervisor's 
station  was  less  critical  in  that 
it  would  be  manned  by  the  most 
experienced  operators,  and  the 
time  available  for  training  and 
testing  did  not  allow  simulation  of 
all  aspects  of  such  a  complex 
system. 

The  scenarios  were  read  to  the 
subjects  one  step  at  a  time  by  the 
experimenter,  who  recorded  the 
subject’s  comments  and  errors. 

A  computer  program  was  written 
to  simulate  the  Contact  Status 
Display  (CSD) .  This  program  was 
updated  whenever  an  operator 
assigned  a  tracker,  correlation 
or  classification  channel,  or 
entered  classification  information 
via  the  Class  Menu  Display.  Every 
15  minutes  of  scenario  time,  the 


5 


simulated  CSD  was  updated  to  reflect 
the  motions  of  all  contacts. 

Printouts  were  available  to  the 
subjects  whenever  they  desired  to 
see  them. 

Three  sets  of  training  materials 
were  used  to  familiarize  the  subjects 
with  the  operation  of  the  system  and 
the  action  of  each  of  the  controls: 

(a)  A  set  of  materials 
describing  each  display  and  associ¬ 
ated  controls  were  prepared  by  NSKRL 
project  members.  These  described 
the  display  layout  and  the  functions 
of  each  VAB.  Subjects  were  instructed 
to  read  through  these  descriptions 
and  to  work  through  the  controls  at 
the  display  terminal,  going  over 

the  material  on  each  display  until 
they  were  comfortable  with  the 
controls  and  their  actions. 

(b)  A  "Common  Procedures"  hand¬ 
out  was  made  up,  listing  the  control 
sequences  required  to  perform  the 
separate  actions,  such  as  assigning 

a  tracker  or  assembling  a  signature, 
by  means  of  which  the  operator  may 
prosecute  a  contact.  Again,  subjects 
worked  through  the  "procedures"  hand¬ 
out  on  the  terminal,  pushing  all  of 
the  buttons  in  sequence. 

(c)  The  TRACOR  Corporation  had 
prepared  a  set  of  scripts  stepping 
through  each  control  action  in  the 
prosecution  of  a  single  contact 
(Bryant,  1979a) .  These  "No  Fault" 
scripts  (modified  to  reflect  the 
keyboard  characters  associated  with 
each  control  on  the  Orion  60)  were 
used  as  the  final  step  in  training. 

The  experimenter  read  the  script  to 
the  subject  who  (usually)  attempted 
to  perform  the  required  actions  with¬ 
out  looking  at  the  script,  though  it 
was  consulted  whenever  he  was  in 
doubt. 


Subj  ects 

Nine  subjects  were  recruited 
from  FBM  off -crews.  The  first  of 
these  participated  in  ironing  out 
flaws  in  the  simulation  and  the 
experimental  procedures.  The 
remaining  eight  participated  in  the 
simulations.  All  were  experienced 
sonar  technicians,  averaging  three 
to  five  years  of  at-sea  experience 
and  having  an  average  rank  of 
STS 2 (SS) .  Each  participated  in 
the  experiment  for  five  full  days, 
approximately  3.5  hours.  . 

Method 

The  timetable  for  the  experiment 
is  given  in  Table  1  (facing) . 

A.  Training.  The  first  three 
days  were  devoted  to  training.  On. 
the  morning  of  the  first  day  the 
system  concept  was  explained  and 
each  of  the  displays  described  in 
detail  with  the  aid  of  the  line 
drawings  in  the  FOD.  The  afternoon 
of  the  first  and  most  of  the  second 
day  were  devoted  to  working  through 
the  materials  describing  the  actions 
of  the  controls  associated  with  the 
separate  displays.  All  of  this 
working  through  was  done  at  the 
terminal ,  and  experimentation  by  the 
subject  was  encouraged.  The  last 
couple  of  hours  of  the  second  day 
were  spent  practicing  with  the 
procedures  handout.  On  the  third 
day,  the  procedures  were  reviewed, 
again  at  the  terminal,  and  the 
TRACOR  "No-Fault"  scripts  for  the 
search  and  class-loc  (and,  if  the 
subject  was  quick,  the  supervisor) 
consoles  were  worked  through.  One 
of  the  experimenters  was  on  hand  to 
answer  questions  throughout  the 
period  of  training.  Display  changes 
resulting  from  VAB  activations  were 
explained  in  detail.  A  frequent 
response  to  questions  of  how  to  do 
something  was  "why  don’t  you  try  it 
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Table  1.  Training  and  Testing  Schedule 

MON  AM  o  Explain  experiment  goals,  limitations  of  simulation 

a.  MPS  (’'Button  Tree")  concept,  VABs  and  FABs 

b.  Display  Select,  Audio,  idea  of  Hooking 

c.  Major  displays  (with  FOD  diagrams) 

PM  o  Leave  subject  to  wcrk  through  all  explanitory  material 

■while  practicing  on  Button  Tree.  Someorae  there  to  answer 
questions,  explain  how  displays  will  look  and  react. 

TUE  AM  o  Continue  working  through  controls  for  each  display 

PM  o  Step  through  important  procedures  using  "common 

procedures"  handout:  emphasize  Hooked  manipulations 
o  (If  time,  begin  TRACOR  No-Fault  Search) 

WED  AM  o  TRACOR  No -Fault  Search 

o  Begin  TRACOR  No -Fault  Class -loc 

PM  o  Finish  TRACOR  No-Fault  Class ’•loc,  begin  Supervisor  if  time 

THU  AM  o  Practice  in  areas  where  subject  weak  on  Tue  or  Wed 

o  Scenario  2  Search  (No  prompting  -  should  be  longest) 

PM  o  Scenario  2  Class -loc 


FRI  AM  o  Scenario  1A  Search 

o  Begin  Scenario  1A  Class -loc 

PM  o  Finish  Scenario  1A  Class -loc 

o  Debrief  -  what  good,  what  seemed  hardest  to  learn, 
suggestions  for  improvement 
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and  see."  The  training  phase  was 
thus  one  of  active  learning  on  the 
subject's  part.  This  learning 
seemed  to  proceed  quickly,  thanks 
in  large  measure  to  the  fact  that 
all  subjects  were  knowledgable 
about  sonar  when  they  came  to  the 
experiment. 

Although  the  training  program 
was  intensive,  none  of  the  subjects 
could  be  said  to  have  mastered  the 
operation  of  all  controls  by  the 
first  day  of  testing.  This  undoubt¬ 
edly  resulted  in  much  higher  error 
rates  than  would  be  encountered  at 
sea.  We  assume,  however,  that  the 
errors  of  our  partially  trained 
operators  will  tend  to  cluster 
around  those  operations  that  are 
less  logically  implemented  or 
simply  more  difficult  to  learn,  and 
it  is  these  same  operations  that 
probably  would  be  responsible  for 
errors  at  sea.  The  skill  of  the 
proficient  operator  may  make 
initially  awkward  or  difficult 
operations  appear  easy,  but  these 
are  the  ones  that  will  trip  up  the 
under-trained,  the  unmotivated,  or 
the  overloaded  operator. 

B.  Testing.  The  test  scenarios 
were  run  on  the  fourth  and  fifth 
days,  the  search  console  sections 
in  the  morning  and  the  class-loc 
sections  in  the  afternoon. 

Scenario  2,  which  has  fewer 
maneuvers  by  own  ship  and  the  threat 
contact,  was  run  first. 

The  subject  was  given  a  handout 
describing  current  shipping  and 
sonar  conditions,  the  expected 
threat,  and  "standard  operating 
procedures"  (assign  trackers  to 
triangulate  where  possible;  do 
multipath  ranging  if  the  contact 
is  in  the  bow  quadrant) .  The 
scenario  was  read  to  the  subject 
one  step  at  a  time  and  he  operated 
the  system  to  deal  with  the  situation 
as  he  thought  best.  Guidance  was 


provided  by  the  experimenter  if 
requested.  Requests  for  guidance, 
errors,  and  subject  comments  were 
recorded  by  the  experimenter,  who 
also  recorded  his  observations  of 
the  subject's  behavior.  An 
assistant  seated  behind  the  subject 
entered  all  resource  assignments  to 
the  Contact  Status  simulation  and 
gave  the  subject  an  updated 
printout  at  the  completion  of  each 
step  in  the  scenario.  At  the 
conclusion  of  the  testing  sessions, 
a  printout  of  all  control  actions 
was  obtained  from  NUSC. 

At  the  end  of  the  last  day  of 
testing,  subjects  were  debriefed. 

Notes  made  during  these  debriefings 
are  presented  in  Appendix  C. 

C.  Analysis.  At  the  conclusion 
of  the  experiment,  the  experimenters 
reconciled  their  notes  to  the  print¬ 
outs  of  control  actions.  Every 
error,  request  for  guidance,  comment, 
observation,  or  (difficult)  question 
concerning  system  operation  was 
written  on  a  5  x  8  card.  All  to¬ 
gether,  346  observations  were 
recorded  for  eight  subjects.  These 
were  sorted  independently  by  the 
authors  into  five  groups:  1)  control 
errors  or  requests  for  guidance;  2) 
questions  about  the  operation  of  the 
system;  3)  comments  by  subject  or 
observer;  4)  those  which  were  very 
difficult  to  classify;  and  5) 
observations  of  no  further  interest 
(system  questions  that  had  been 
resolved  satisfactorily,  and  notes 
describing  difficulties  or  unusual 
occurrences,  such  as  computer  failure) 
The  first  three  categories  were  not 
mutually  exclusive.  For  example, 
an  error  could  be  associated  with 
a  question  of  system  operation. 

The  initial  sorts  were  reconciled 
and  reduced  to  four  categories: 

1)  errors  or  request  for  guidance; 

2)  system  questions;  3)  comments; 
and  4)  observations  of  no  further 
interest. 
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Errors  or  requests  for  guidance 
were  described  by  133  cards.  This 
represents  a  raw  error  rate  of  3.45% 
of  3855  recorded  control  actions. 
Another  76  cards  posed  questions 
about  system  operation.  These 
209  cards  were  sorted  into  three 
categories:  1)  errors  or  comments 
pointing  to  a  need  for  the  redesign 
of  the  man -machine  interface;  2) 
errors  suggesting  areas  that  should 
be  given  emphasis  in  training;  and 
3)  errors  clearly  reflecting 
deficient  mastery  of  the  more 
basic  aspects  of  the  system. 

Category  3  included  such  errors  as 
inadvertent  selection  of  a  control 
or  not  knowing  which  control  to 
select  to  complete  a  sequence.  Items 
in  this  category  were  dropped  from 
further  consideration  as  it  was 
felt  that  they  reflected  failures 
on  the  part  of  the  individual 
subject  instead  of  defects  in  the 
system  itself.  The  remaining  cards 
were  then  resorted  independently 
by  the  two  investigators  into 
subgroups  relating  to  specific 
control  operations.  Agreement  on 
the  third  sort  was  approximately  75%. 
Disagreements  were  mostly  due  to 
the  fact  that  an  observation  could 
fit  into  more  than  one  category. 
Disagreements  were  reconciled  on  a 
case-by-case  basis. 

It  is  recognized  that  there  is 
a  large  subjective  component  in 
these  procedures.  To  make  the 
evaluation  as  objective  as  possible, 
analysis  has  (with  a  few  exceptions) 
been  confined  to  problems  resulting 
in  docuraentable  errors,  i .e.,  obviously 
inappropriate  control  activations . 
Nevertheless,  a  certain  degree  of 
subjectivity  is  inherent  in  any 
evaluation.  In  the  present  case, 
the  authors ’  judgments  were  informed 
by  familiarity  with  the  system 
documentation  and  close  observation 
of  the  subjects  during  the  training 
and  testing  phases  of  the  experiment. 


The  authors  are  confident  that  the 
problems  described  below  are  of  some 
generality,  as  opposed  to  reflecting 
simply  the  idiosyncratic  misunder¬ 
standings  of  particular  individuals, 
even  when  the  problem  only  occurred 
for  one  man . 

As  previously  noted,  the 
simulation  and  testing  was  confined 
to  the  displays  and  associated 
controls  used  by  operators  of  the 
search  and  class-loc  consoles. 

Awkward  implementations  and  common 
errors  are  described  below,  along 
with  recommendations  for  reducing 
the  likelihood  of  the  error  being 
committed  or  the  time  to  recover  if 
it  is.  The  problems  are  loosely 
grouped  according  to  the  nature  of 
the  difficulty.  A  majority  of  the 
proposed  modifications  have  to  do 
with  making  the  system  more  trans¬ 
parent  or  increasing  the  information 
available  to  the  operator. 

It  is  recognized  that  many  of  the 
problems  described  would  not  arise 
at  the  hands  of  a  well  trained  and 
experienced  operator.  However,  a 
significant  proportion  of  the 
operators  will  be  non-rated  watch- 
stand  ers  or  junior  sonarmen  who  must 
learn  the  system  on  the  job.  The 
proposed  modifications  would  make 
the  operation  of  the  system  easier 
for  the  beginning  operator  and  all 
are  in  keeping  with  the  design 
emphasis  on  operability. 

Problems  relating  to  the  assign¬ 
ment  of  contact  data  to  the  correct 
system  file  are  listed  in  Table  2 
(overleaf).  A  general  summary -of  the 
problem  is  given  in  the  Problem 
Description  column.  Suggested 
solutions  are  presented  in  the 
Solution  Proposed  column.  The  two 
numbers  in  parenthesis  at  the 
beginning  of  the  problem  description 
give  the  number  of  times  the  error 
was  recorded  and  the  number  of 
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Tahle  2 


File  Errors 


Problem  problem  Description 

1  (8/2)  Initialized  tracker  on 
second  contact  while  still 
hooked  to  first  contact* 

2  (4/4)  Contact  tracked  on  PL 
appears  on  BIB  display,  pushed 
"new  trace  at  bearing"  (1,1-0) 
instead  of  "hook  at  bearing" 
(1.1-1)  to  add  BB  tracker. 

3a  (6/4)  Pushed  "new  trace  at 
bearing"  (1.1-0)  instead  of 
"hook  at  bearing"  (1.1-1)  as 
first  step  in  adding  a  second 
tracker  to  triangulate 
contact. 

3>b  (3/3)  Pushes  "new  trace"  or 

"new  line"  in  attempt  to  gain 
access  to  a  contact's  file. 

4  (11/3)  Subject's  natural  re¬ 

action  to  "sonar  threat"  is 
to  push  "hook  threat" 

(1.3. 1.1-2  OR  2. 6. 6-2)  which 
creates  a  new  file.  The 
options  reached  by  hooking 
the  threat  (1.2. 3. 1.3  or 
2. 6. 5. 1.3)  do  hot  allow  a 
graceful  recovery  if  the 
operator  realizes  the  threat 
is  not  a  new  contact. 


Solution  Proposed 

System  test  for  wide  disparity  between 
BCV  and  bearing  of  hooked  file,  and 
cue  "cursor  not  on  hooked  file  bearing. 

System  test  and  cue:  "Sierra  #  at 
bearing  selected."  Change  1.1-0 
label  to  "new  contact  at  bearing." 


System  test  and  cue:  "Sierra  #  at 
bearing  selected."  Change  1.1-0 
label  to  "new  contact  at  bearing." 


Add  "return  to  previous  options" 
escape  to  tiers  1.2. 3. 1.3  and 
2. 6. 5. 1.3.  Change  "hook  threat"  VAB 
(1.2. 1.1-2  and  2. 6. 6-2)  to  "hook 
new  threat"  and  add  a  "hook  file 
at  threat  bearing"  function. 


individual  subjects  committing  the 
error.  The  observations  which  led 
to  the  identification  of  the 
problem  are  presented  in  Appendix  B. 

The  first  problem  described 
in  Table  2  is  probably  the  most 
important  problem  isolated  during 
the  course  of  the  simulations. 
Subjects  frequently  neglected  to 
drop  hook  when  they  had  finished 
dealing  with  a  contact.  When 
they  then  began  to  prosecute  a 
second  contact,  any  trackers 
assigned  to  the  second  contact 
went  into  the  first  contact 1 s 
file.  This  error  is  very  serious 
for  two  reasons.  It  is  uncertain 
how  the  additional  trackers  at 
divergent  bearings  would  affect 
ongoing  contact  motion  analysis 
(CMA)  of  the  first  contact. 

Secondly,  the  tracker  (or  other 
resource)  assigned  would  be 
functionally  useless  as  the  data 
it  produced  would  go  into  the 
wrong  file.  In  addition,  should 
the  second  contact  be  a  new  one, 
entering  it  to  an  old  file  would 
prevent  its  appearing  on  the 
contact  status  display,  thus 
effectively  concealing  its 
existence.  Presumably  an 
alert  supervisor  would  detect 
the  absence  of  a  new  file  when  a 
new  contact  was  reported,  but 
if  he  was  not  looking  at  the 
contact  status  display  a  considerable 
time  might  elapse  before  the 
error  was  corrected. 

The  most  obvious  solution  to  this 
problem  is  more  careful  operation 
of  the  system.  Operators  should 
be  trained  to  be  aware  that  system 
performance  can  be  seriously  de¬ 
graded  by  mis-filing  of  information. 
It  is  recommended  that  unhooking 
immediately  upon  completion  of  any 
hooked  operation  be  incorporated 
as  a  standard  operating  procedure5 . 
Maintaining  hook  when  not  actively 
prosecuting  a  contact  invites  file 


errors.  This  particular  error 
would  be  rendered  much  less  likely 
if  the  system  were  to  warn  the 
operator  when  the  bearing  cursor 
strayed  too  far  from  the  bearing 
of  the  hooked  file.  It  is  proposed 
that  the  system  test  for  disparity 
between  the  bearing  cursor  position 
and  the  bearing  of  the  hooked  file 
and  that  the  cue  "cursor  not  on 
hooked  file  bearing"  appear  in  the 
cue  area  when  the  bearing  cursor 
wanders  too  far  afield.  The 
proposed  test  should  not  be 
difficult  to  implement,  since 
routines  for  comparing  the  cursor 
position  against  the  file  position 
are  already  a  part  of  the  software. 
For  example,  activation  of  "hook 
at  bearing"  currently  requires  the 
system  to  search  the  files  for  a 
contact  at  the  bearing  cursor 
position. 

Problem  2  arises  when  a  contact 
is  being  tracked  on  "difar-like" 

(DL) ^  and,  after  some  delay,  also 
appears  on  the  broad-band  (BB) 
display.  There  is  no  indication 
on  the  BB  displays  that  a  tracker 
is  assigned  on  the  DL,  and  the 
tracker  symbols  on  the  DL  display 
do  not  indicate  the  bearing  to 
which  they  are  assigned.  Thus,  a 
DL  contact  that  had  been  tracking 
in  automatic  target  following  (ATF) 
for  a  time  may  appear  at  a  relatively 
unexpected  position  on  the  BB 
display5.  A  similar  situation  can 
occur  in  the  case  of  a  contact 
that  is  being  tracked  broad-band 
on  the  array  that  is  not  being 
displayed  (e.g.,  the  contact  is 
tracking  in  the  conformal  array 
when  the  operator  is  monitoring 
the  cylinder  and  towed  arrays) . 

The  operator's  initial  reaction  on 
seeing  a  new  trace  on  the  BB  display 
is  to  push  the  "new  trace  at  bearing" 
VAB.  In  the  case  described,  this 
action  would  result  in  the  creation 
of  a  second  file  on  the  same  contact 
and  also  the  appearance  that  there 
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were  two  contacts  where  there  was, 
in  fact,  only  one.  Again,  more 
deliberate  operation  of  the  system 
would  prevent  this  error  in  the 
majority  of  cases.  Additional 
protection  could  be  proyided  if 
the  system  were  to  test  the  position 
of  the  hearing  cursor  against  the 
position  of  current  files  and  warn 
the  operator  if  he  were  about  to 
create  a  file  at  the  position  of 
another  current  file.  Since  this 
warning  would  be  elicited  by  the 
activation  of  the  "new  trace"  VAB , 
activations  resulting  in  such 
warnings  should  not  also  create  a 
new  file.  However,  since  it  is 
possible  that  the  operator  will,  on 
occasion,  have  separate  contacts  at 
similar  bearings,  it  should  be 
possible  to  override  the  warning, 
perhaps  by  pushing  the  VAB  a  second 
time  while  the  cue  was  still  being 
displayed.  On  the  second  button 
push  the  new  file  would  be  created. 

The  present  VAB  label  "new 
trace  at  bearing"  is  misleading. 
Subjects  stated  that  it  is  a 
general  policy  to  consider  all  DIMUS 
traces  to  represent  contacts  until 
proven  otherwise.  The  "new  trace" 
VABs  are  used  solely  to  indicate 
the  detection  of  a  new  contact. 

They  should  be  so  labelled.  The 
"new  line  at  XXX  and  bearing"  VABs 
of  the  DL  Search  and  Class-Summary 
displays  are  similarly  misleading. 
They,  too,  are  used  only  to  signal 
a  new  contact.  However,  most 
contacts  exhibit  multiple  lines,  so 
a  new  line  does  not  necessarily 
imply  a  new  contact  (as  does  a  new 
DIMUS  trace).  The  "new  line  ..." 
labels  should  be  changed  to  read 
"new  contact  at  XXX  and  bearing." 

Five  of  our  subjects  also 
attempted  to  use  the  "new  trace"  or 
"new  line"  VABs  to  gain  access  to  a 
file,  in  lieu  of  hooking  that  file 
(problem  3).  Although  these  errors 
are  plainly  the  result  of  insufficient 


understanding  of  the  system,  they 
too  would  be  made  much  less  likely 
by  the  provision  of  the  system 
test  and  cue  as  suggested  in  the 
solution  to  problem  2. 

A  number  of  errors  centered 
around  responses  to  the  "sonar 
threat"  alert  function.  Although 
this  feature  is  of  great  potential 
importance,  it  does  not  appear 
to  have  been  as  well  thought  out 
as  most  other  aspects  of  the  ISPE 
system.  Acknowledgement  of  a 
sonar  threat  by  activation  of  FAB 
16  brings  up  tiers  1.2. 1.1  (on 
DLS )  and  2.6.6  (on  Class-Summary) ^ 
These  allow  the  operator  only  4 
responses  to  the  threat.  He 
can  hook  the  threat  (VAB  2) , 
thereby  creating  a  new  file ;  he 
can  enter  the  threat  to  an  existing 
file  (VAB  4) ;  he  can  acknowledge 
an  alarm  generated  by  the  BQR-19 
(VAB  6) ;  or  he  can  dismiss  the 
threat  as  a  false  alarm  (VAB  8) . 

Experience  indicates  that  threat 
alerts  will  be  triggered  often; 
almost  always  by  non -threat  contacts 
and  frequently  by  own  ship.  The 
threat  alert  function  would  be  more 
usable  if  it  were  more  flexibly 
implemented.  For  example,  the 
present  "enter  to  file"  option 
(VAB  4)  requires  that  the  operator 
supply  the  file  number.  Response 
would  be  facilitated  if  the 
system  would  indicate  the  number  of 
the  file  (or  preferably  the  Sierra 
number)  of  the  contact  at  the  threat 
bearing,  which  could  be  determined 
by  a  test  like  that  proposed  in 
response  to  problems  2  and  3. 
Alternatively,  entry  of  the  threat 
line  to  a  pre-existing  file  could 
be  speeded  up  by  replacing  the 
present  "enter  to  file  #"  VAB  with 
one  having  a  slightly  different 
function;  "put  in  file  at  bearing" 
(limitation  of  "enter"  to-mean 
enter  via  the  keyboard  is  discussed 
in  connection  with  Table  5  below) . 
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The  present  "hook  threat"  VAB 
creates  a  new  file.  This  is  the 
only  place  in  the  system  where 
" hook "  creates  a  file  instead  of 
accessing  a  pre-existing  one. 

There  is  no  way  of  hooking  an 
existing  file  from  the  sonar 
threat  tier.  Inasmuch  as  a 
threat  contact  may  trigger 
several  alerts,  hooking  the 
existing  file  directly  in  order 
to  further  prosecute  the  contact 
seems  a  desirable  option. 

The  present  "hook  threat" 
function  also  has  another  serious 
flaw:  when  it  is  selected,  the 

options  then  presented  to  the 
operator  do  not  allow  an  easy 
recovery,  should  he  realize  that 
the  contact  triggering  the  alert 
is  already  on  file.  This  is  a 
notable  amission  in  view  of  the 
availability  of  retrace  sequences 
for  other  functions.  To  remedy 
this  deficiency,  a  "return  to 
previous  options"  VAB  should  be 
added  to  control  tiers  1.2. 3. 1.3 
and  2 . 6 . 5 . 1 . 3 . 

It  is  proposed  that  a  "hook 
file  at  bearing"  option  be  added 
to  the  sonar  threat  acknowledgement 
tiers  on  DLS  and  Cla ss -Summary . 
Further,  the  current  "hook  threat" 

VAB  should  be  relabelled  "hook  new 
threat",  and  the  current  "enter  to 
file  #"  function  should  be  changed  to 
"put  in  file  at  bearing:"  The 
proposed  sonar  threat  acknowledgement 
tier  would  be: 


In  addition,  upon  acknowledgement 
of  the  sonar  threat,  the  system 
should  review  the  contact  status 
file  and  display  one  of  two  cues: 
"Sierra  #  (or  file  #)  at  threat 
bearing"  or  "no  contact  presently 
at  threat  bearing . ” 

The  proposed  changes  appear  to  be 
rather  extensive;  they  are  not. 

"Hook  new  threat"  is  merely  a  more 
accurate  label  for  the  present  "hook 
threat"  function.  "Hook  file  at 
bearing , "  while  new  to  the  threat 
acknowledgement  tier,  is  already 
implemented  on  the  BB  and  Class- 
Summary  displays.  The  "put  in 
file  at  bearing"  function  is  the 
only  new  one,  but  .requires  only  that 
the  system  search  the  contact  files 
for  the  one  at  the  bearing  of  the 
signal  causing  the  alert.  The  two 
operator  cues  are  also  selected  by 
the  results  of  such  a  search,  which 
is  similar  to  the  search  initiated 
by  the  "hook  at  bearing"  commands. 

Table  3  (overleaf)  describes  some 
features  of  the  system  which  appear 
to  be  awkwardly  implemented. 

Problems  5,  6,  and  7a  are  all 
instances  of  controls  being  in¬ 
accessible  when  the  console  is  in 
the  hooked  mode.  In  all  cases,  this 
limitation  of  access  when  hooked 
appears  to  be  arbitrary  and  may  be 
counter-productive.  Being  unable  . 
to  switch  the  broad -band  sensor 
displayed  while  the  console  is  in  the 
hooked  mode  (problem  5)  is  probably 
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Table  3,  Awkward  Implementations 


Problem  Problem  Description 

5  (3/3)  Cannot  change  BB  arrays 
displayed  when  hooked, 

6  (9/4)  Cannot  assign  a  class™ 
if  ication  .-channel  via  CS  when 
contact  is  hooked. 

7a  (3/3)  LAMPAZ  assignment  via 
CS  not  accessible  when  hooked. 

7b  (4/2)  Transfer  of  single 

lines  to  LAMPAZ  via  signature 
assembly  tier  awkward. 

Erasure  of  lines  from 
contacts  other  than  the 
one  hooked  reduces  utility 
as  sorting  aid. 

8  (1/1)  "Release  indexed  corr 
ch"  (3.4.0. 1-4)  and  "release 
indexed  class  ch"  (3. 4. 0.1-6) 
VABs  on  CSD  have  automatic 
return  to  PFD  top  position: 

A  nuisance  when  want  to 
release  both  class  and 
correlation  channels. 

9  (2/2)  Harmonic  comb  comes 
up  on  the  "off"  state  if 
the  operator  turned  it  off 
when  last  used. 


Solution  Proposed 

"Display  Source  Select"  VAB  should 
be  accessible  when  hooked. 

Class  channel  assignment  tiers 
should  be  ayailable  when  hooked. 


LAMPAZ  assignment  should  be 
available  when  hooked. 


Drop  automatic  return,  return  via 
"return  to  previous  options"  VAB. 


Harmonic  comb  should  always  come 
up  in  the  "on"  state  when  selected. 
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simply  a  minor  inconvenience,  as 
the  operator  may  not  want  to  do 
this  frequently,.  However,  the 
operator  should  be  able  to 
assign  a  classification  channel 
on  the  Class-Summary  display 
when  the  console  is  in  the 
hooked  mode  (problem  6) .  To 
assign  a  classification  channel 
to  a  hooked  contact  or  a  second 
contact  while  prosecuting  a  hooked 
contact,  the  operator  can  use 
the  Contact  Status  Display,  or 
unhook  to  access  the  classification 
channel  assignment  controls  on 
Clas s -Summary .  In  the  former 
case,  the  Contact  Status  Display 
would  temporarily  replace  either 
the  Class-Summary  or  the  Class- 
Analysis  display.  Either  sequence 
is,  at  best,  a  nuisance,  and  cpuld 
result  in  significant  delays  or 
errors  if  the  system  or  operator 
were  heavily  loaded. 

The  controls  on  the  Classification 
Summary  Display  that  assign  lines 
to  the  LAMPAZ  (line  amplitude- 
azimuth)  display  are  not  accessible 
when  the  console  is  in  the  hooked 
mode  (problem  7a) .  Assuming  that 
the  primary  function  of  LAMPAZ  is 
as  an  aid  to  contact  sorting,  it 
follows  that  LAMPAZ  should  be  used 
most  frequently  during  classification 
and  signature  assembly.  The 
signature  assembly  feature  requires 
that  the  console  be  hooked,  in 
which  case  assignment  of  lines  to 
LAMPAZ  is  not  presently  possible. 

The  inaccessibility  of  LAMPAZ 
while  in  the  hooked  mode  represents 
an  unnecessary  limitation  on  the 
usefulness  of  this  feature.  The 
technique  of  transferring  trial 
signatures  to  LAMPAZ  directly  from 
the  Signature  Assembly  field  has 
the  significant  drawback  of  over¬ 
writing  lines  from  contacts  other 
than  the  one  hooked  (problem  7b) . 
Again,  this  would  seem  to  limit 
the  usefulness  of  the  LAMPAZ  display 
as  a  sorting  aid.  Although  the 


presently  implemented  capability 
of  transferring  entire  signatures 
to  LAMPAZ  is  a  desirable  feature, 
the  ability  to  transfer  individual 
lines  without . erasing  lines  which 
may  be  coining  from  other  contacts 
is  also  very  desirable,  and  could 
be  accomplished  simply  by  allowing 
access  to  the  regular  LAMPAZ  assign¬ 
ment  controls  while  hooked. 

The  control  options  associated 
with  the  Contact  Status  Display  at 
the  supervisor's  console  are  more 
extensive  than  those  associated 
with  the  same  display  on  the  class- 
loc  and  search  consoles.  On  the 
supervisor  display,  assignment  and 
release  of  correlation  and  class¬ 
ification  channels  are  accomplished 
by  means  of  a  separate  control  tier 
(3. 4. 0.1).  Releasing  of  either  a 
correlation  or  a  classification 
channel  on  this  tier  results  in 
automatic  return  to  the  top  tier  of 
the  supervisor  Contact  Status 
Display  (problem  8) .  Although 
this  automatic  return  is  intended 
to  save  the  operator  the  trouble 
of  returning  via  a  separate  button 
push,  it  is  as  likely  to  be  a 
nuisance  because  one  of  the  more 
common  reasons  for  releasing 
classification  or  correlation  channels 
through  this  display  is  to  release 
all  resources  prior  to  dropping  a 
tracker®.  Thanks  to  the  automatic 
return  feature,  the  operator  must 
access  the  "manage  corr/class 
channel"  tier  (3. 4. 0.1)  for  each 
correlation  and  classification 
channel  to  be  released.  This  is  a 
case  where  automatic  return  may 
actually  impede  the  operator ’ s 
actions.  A  manual  "return  to 
previous  options"  YAB  should  replace 
the  automatic  return  feature. 

The  status  of  the  harmonic  comb 
when  selected  by  means  of  the 
harmonic  comb  control  tiers  on  DLS 
or  Classification  Summary  is 
determined  by  the  last  selected 
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position  of  the  "harmonic  comb 
on/off"  VAB  on  the  harmonic  comb 
control  tier.  Thus,  it  is 
possible  for  the  harmonic  comb  to 
come  up  in  the  "off"  state  if  the 
operator  turned  it  off  when  it  was 
last  used  (problem  9) .  The  controls 
for  the  harmonic  comb  should  be 
modified  so  that  the  comb  always 
comes  up  in  the  "on"  state  when  the 
operator  selects  the  harmonic  comb 
control  VABs  on  DLS  or  Class-Summary. 

Errors  or  subject  comments 
revealed  several  instances  in  which 
VAB  labels  were  either  inconsistent 
or  less  informative  than  they  might  be . 
These  are  summarized  in  Table  4 
(facing) . 

The  most  glaring  instance  of  an 
inconsistent  control  label  is  "enter 
line  at  XXX"  (problem  10) .  This 
control  places  lines  directly  into 
the  contact's  file  from  DLS,  Class- 
Summary,  and  the  top  hooked  tier  on 
Class-Analysis.  In  the  signature 
assembly  mode,  the  "enter  line  at 
XXX"  VAB  (2. 7. 6. 2-5)  has  a  very 
different  function:  this  control  is 
used  to  transfer  lines  from  one  of 
the  grams  to  the  signature  assembly 
field.  This  VAB  should  be  relabelled 
"move  line  to  signature,"  which  is  a 
more  accurate  description  of  its 
function.  Also  in  the  interest  of 
accurate  description,  VAB  2. 7. 6. 2 -4, 
"enter  lines  displayed,"  which  some 
of  our  subjects  confused  with  "enter 
line  at  XXX,"  should  be  relabelled 
"put  signature  in  file." 

Five  subjects  had  difficulty 
remembering  that  the  CMA  update 
functions  were  accessed  via  the 
"localization/range  history"  control 
(problem  11).  Since  the  range 
history  plot  is  only  one  of  the 
functions  accessed  by  this  tier, 
and  is  in  fact  a  part  of  CMA,  a 
better  label  for  this  control 
would  be  "rang ing /CMA. " 


Classification  channel  assignment 
sequences  on  the  Class-Summary  and 
Contact  Status  displays  conclude 
with  the  processing  options  "full 
band  process" ' (VABs  2. 6, 2. 2-3  and 
3. 4. 0.3-3)  and  "extended  range 
process"  (YABs  2. 6, 2. 2 -5  and 
3. 4. 0.3-5).  Classification  channel 
processing  is  altered  on  the  Class- 
Analysis  Display  by  VAB  2.7-5, 

"clas  ch  procssng  ext/norm."  Since 
the  "full"  band  is  expected  to  be 
the  processing  normally  assigned,  it 
is  recommended  that  VABs  2. 6. 2. 2-3 
and  3. 4. 0-3  be  relabelled  "normal 
band  process." 

One  subject  apparently  thought 
that  the  "compute  range"  VAB 
(2. 7. 6. 1-3)  on  the  multipath  ranging 
tier  both  calculated  the  range  and 
entered  this  range  to  the  on-going 
CMA  (problem  13) .  The  more  limited 
function  of  this  control  would  be 
more  accurately  indicated  if  it  were 
labelled  "compute  trial  range." 

One  subject  remarked  that  the 
"select  vernier  process"  (VAB  2.7-2) 
control  label  was  too  much  like 
"select  demon/vernier  display" 

(VAB  2.7-3),  to  which  it  is  adjacent 
on  the  Class-Analysis  Display 
(problem  14) .  The  function  of  this 
control  would  be  more  accurately 
conveyed  if  the  label  were  changed 
to  "assign  vernier  process." 

In  the  interest  of  clarity  and 
consistency,  it  is  recommended  that 
the  word  "enter"  be  reserved  for 
controls  that  initiate  numerical  entry 
by  means  of  the  keypad.  Another 
word  will  almost  always  be  more 
descriptive  of  the  actual  function 
of  those  controls  that  do  not  initiate 
such  input.  In  order  to  be  consistent 
"enter"  should  also  appear  on  those 
controls  which  require  numerical 
entry  but  do  not  have  "#"  as  a  part 
of  the  label.  Table  5  (overleaf) 
summarizes  the  VAB  labels 


Table  4.  Confusing  VAB  Labels 


Problem  Problem  Description 

10  (8/6)  Inappropriate  selection 
of  ''enter  line  at  XXX" 

(2. 7. 6. 2 -5)  and  "enter 
lines  displayed"  (2. 7. 6. 2 -4) 
in  signature  assembly  tier. 
"Enter  line  at  XXX"  (2. 7. 6. 2 -5) 
has  different  function  in 
signature  assembly  (2. 7. 6. 2) 
tier  and  tier  2.1.6,  where 
VAB  2. 7. 6 -5  enters  to  the 
hooked  file  directly. 

11  (6/5)  Difficulty  remembering 
CMA  accessed  via  "lclztn/ 
range  history"  (2. 7. 6-0) . 

12  (1/1)  Classification  channel 
assignment  sequences  on  CS 
and  CSD  conclude  with  the 
processing  options  "full  band 
process"  (2 .6 .2 .2-3/3 .4 .0.3-3) 
and  "extended  range  process" 

(2. 6. 2. 2-5/3. 4.0. 3-5) :  The 
analogous  control  on  CA  is 
"class  ch  process  ext/norra" 
(2.7-5). 

13  (1/1)  Apparent  confusion  of 
function  of  "compute  range" 

(2. 7. 6. 1-3)  and  "enter 
computed  range"  (2. 7. 6. 1-8)  on 
CA  MPR  tier. 

. 14  (1/1)  CA  "select  vernier 

process"  (2.7-2)  much  like 
"select  dem/vern  display" 
(2.7-3)  . 


Solution  Proposed 

Change  2. 7. 6. 2 -5  label  to  "move 
line  to  signature"  and  2. 7. 6. 2 -4 
to  "put  signature  in  file." 


Change  2.7.6-0  lebel  to  "ranging/CMA. 


Change  2. 6. 2. 2 -3  and  3. 4. 0.3 -3 
labels  to  "normal  band  process. 


Change  2. 7. 6. 1-3  to  "compute  trial 
range . " 


Change  2.7-2  and  2. 7. 6-2  labels 
to  "assign  vernier  process." 
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Table  5 


"ENTER"  yABs  to  be  Changed 


VAB  #  Present  Babel 


A,  Inappropriate  "ENTER"  yABs 


1.1 .1- 8  Enter 

1.1. 3- 8  Enter 

1.2. 3 - 5  Enter 

1.2. 3. 2 - 7  Enter 

2. 6. 3- 3  Enter 

2.6. 5- 5  Enter 

2 . 6 . 5 . 2 - 7  Enter 

2 . 7 . 6 - 6  Enter 

2. 7. 6. 1- 8  Enter 

2. 7. 6. 2- 4  Enter 

2 . 7 . 6 . 2 - 5  Enter 

2. 7. 6. 2. 2 - 7  Enter 

3. 3. 1-0  Enter 


ping  Bearing 
ping  bearing 
line  at  XXX 
fund  XXX 
cursor  XXX 
line  at  XXX 
fund  XXX 
line  at  XXX 
computed  range 
lines  displayed 
line  at  XXX 
fund  XXX 
indexed  data 


Proposed  Babel 


Mark  ping  bearing 
Mark  ping  bearing 
Put  line  in  file 
Put  fund  in  file 
Use  cursor  XXX 
Put  line  in  file 
Put  fund  in  file 
Put  line  in  file 
Use  computed  range 
Put  signature  in  file 
Move  line  to  signature 
Put  fund  in  file 
Record  indexed  datum 


B.  Suggested  "ENTER"  VABs 


3.13-0 

Sea  state  number 

Enter 

sea  state 

3.13.1-3 

Towed  array  depth 

Enter 

towed  depth 

3.13.1-5 

Own  ship  depth 

Enter 

own  ship  depth 

3.13.4-0 

Towed  array  gain 

Enter 

towed  gain 

3.13.4-1 

Towed  array  loss 

Enter 

towed  loss 

3.13.4-3 

Confml  array  gain 

Enter 

confml  gain 

3.13.4-4 

Confml  array  loss 

Enter 

confml  loss 

3.13.4-6 

Cylndcl  array  gain 

Enter 

cylndcl  gain 

3.13.4-7 

Cylndcl  array  loss 

Enter 

cylndcl  loss 
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that  should  be  changed. 

Table  6  (oyerleaf)  lists 
several  situations  in  which  the 
presentation  of  additional  or 
simply  more  accurate  feedback 
to  the  operator  would  facilitate 
his  responses. 

There  is  no  indication  of 
the  number  of  the  tracker  which 
is  assigned  by  operator  action  on 
the  BB  and  DLS  displays  (problem 
15) .  Providing  this  information 
would  lessen  reliance  on  the 
Contact  Status  Display  and 
facilitate  handoff  of  the  contact 
to  the  classification  operator. 

It  would  also  speed  MTB  assign¬ 
ment  in  the  case  where  the  signal 
was  too  weak  for  the  tracker  to 
lock  on  in  ATF  (control  normally 
returns  to  the  top  tier  when 
"ATF  assign"  is  selected,  whether 
the  tracker  locks  on  or  not) .  It 
is  proposed  that  the  system  be 
altered  so  that  the  tracker  number 
assigned  by  an  operator  action 
would  be  displayed  briefly  in 
the  cue  area. 

One  of  the  responses  on  the 
present  sonar  threat  acknowledgement 
tier  (1.2. 1.1  and  2.6.6)  is 
"enter  (the  threat  line)  to 
file  #."  The  file  number  may  not 
be  readily  available  to  the  operator 
(problem  16) .  The  primary  source 
of  file  numbers  is  the  Contact 
Status  Display,  which  may  not 
be  displayed  at  the  time  of  the 
threat.  Since  the  system  determines 
the  bearing  of  the  signal  trigger¬ 
ing  the  threat,  it  should  be 
comparitively  simple  to  search  the 
contact  files  and  identify  the 
file  at  that  bearing  (or  determine 
that  there  was  no  file  at  the 
bearing) .  It  is  proposed  that 
such  a  test  be  added  to  the 
operating  system,  and  that  the 
results  of  the  test  be  displayed 
in  the  cue  area  as  "file  #  at 


threat  bearing"  or  "no  contact 
presently  at  threat  bearing."  This 
addition  was  suggested  as  a  part  of 
the  proposed  redesign  of  the  threat 
alert  response  tier  (problem  4)  and 
is,  of  course,  unnecessary  if  that 
redesign  is  implemented. 

On  a  number  of  occasions,  the 
sonar  threat  alert  was  activated 
while  the  operator  was  not  looking 
at  one  of  the  DL  displays  (problem 
17 ) .  Acknowledgement  of  the  alert 
in  this  circumstance  results  in  the 
appearance  of  the  cue  "select  DL 
Search."  On  three  occasions, 
operators  blindly  followed  the 
displayed  cue  when  selection  of 
Class-Summary  would  have  been  a 
better  choice.  The  cue  displayed 
should  be  "select  DL  Search  or 
Class-Summary  Display." 

In  a  number  of  cases,  operators 
attempted  to  activate  a  VAB 
(problem  18a)  or  a  FAB  (18b  and  18c) 
in  the  interval  between  selection 
of  a  control  initiating  numeric 
entry  and  the  actual  entry  of  the 
required  numbers.  These  actions 
result  in  the  display  of  rather 
nonspecific  error  cues,  either 
"invalid  command"  or  "selection 
invalid."  A  more  informative  cue, 
"complete  numeric  entry/"  should  be 
provided.  It  should  be  noted  that 
these  problems  may  be  an  artifact 
of  the  simulation  used  in  this 
study:  the  system  blanks  all  VAB 
labels  when  a  numeric  entry  is 
pending,  but  this  feature  was 
suppressed  in  the  simulation.  The 
number  of  errors  of  this  kind 
observed  supports  the  wisdom  of 
blanking  the  VAB  labels.  Since  this 
kind  of  error  is  likely  only  when 
the  operator  has  been  distracted, 
displays  allowing  more  than  one  kind 
of  numeric  data  to  be  entered,  such 
as  the  Class-Menu,  would  benefit 
from  a  more  unambiguous  cueing 
procedure  than  simply  blanking  all 
VAB'lab'els.  Here  two  VABs  initiate 
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Table  6.  Additional  Information  Desirable 


Problem  Problem  Description 

15  (1/1)  BB  &  DBS  displays 
do  not  show  tracker 
number  of  tracker  assigned 
by  operator  action, 

16  (3/2)  How  dbes  operator 
know  file  number  of 
contact  causing  "sonar 
threat"?  (Problem  on 
DLS  only) 

17  (3/2)  Pushed  "sonar 

threat"  (FAB  16)  while 
neither  CS  or  DLS  was 
displayed:  cue  "select 

DL  search"  obeyed  when 
CS  would  have  been 
better  choice. 

18a  (2/2)  Attempted  to  activate 
a  VAB  while  numeric  entry 
is  pending:  cue  "invalid 
command"  not  helpful. 

18b  (4/4)  Attempted  to  drop 
hook  (FAB  10)  while 
numeric  entry  is  pending: 
cue  "selection  invalid" 
not  helpful. 

18c  (1/1)  Pushed  "sonar  threat" 
(FAB  16)  while  numeric  entry 
is  pending  on  CM:  cue 
"selection  invalid"  not 
helpful . 


Solution  Proposed 

Display  number  of  the  tracker 
assigned  by  operator  action 
in  cue  area. 


Cue  "Sierra  # _  at  threat 

bearing  or  VAB  "enter  to  file 
at  bearing." 


Cue  "select  DL  search  or  class 
summary  display." 


Cue  "complete  numeric  entry." 


Cue  "complete  numeric  entry." 


Cue  "complete  numeric  entry . " 
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numeric  entry,  and  blanking  does 
not  indicate  which  one  was 
selected.  A  more  foqlproof 
procedure  wculd  be  to  blank  all 
VAB  labels  except  the  one 
initiating  the  numeric  entry 
sequence. 

Table  7  (oyerleaf)  lists 
miscellaneous  problems  and 
observations  made  during  the 
course  of  the  simulations. 

A  subject  was  observed  to 
activate  the  "enter  computed 
range"  VAB  (2. 7. 6. 1-8)  on  the 
multipath  ranging  display  twice 
upon  completion  of  ranging 
(problem  19) .  The  effect  such  a 
spurious  entry  would  have  on  the 
ongoing  CMA  could  not  be  determined. 
Although  errors  of  this  kind  are 
hardly  specific  to  ISPE,  many 
computerized  systems  can  be  hung 
up  by  unanticipated  inputs. 

The  system  designers  should  be 
aware  that  such  illogical  inputs 
will  inevitably  occur  and  protect 
the  system  from  undue  sensitivity 
to  them . 

Although  the  system  warns  of 
crossing  contacts  (problem  20) ,  the 
subjects  were  unable  to  determine 
the  best  procedure  for  dealing 
with  a  tracker  which  had  been 
captured  by  a  crossing  contact. 
Specific  procedures  for  dealing 
with  this  occurrence  should  be 
included  in  system  operating 
guidelines. 

The  detection  of  transients  is 
a  relatively  common  occurrence 
(problem  21) .  It  is  unclear  how 
information  about  transients  can 
be  entered  into  the  system. 

Specific  guidelines  for  dealing 
with  transients  and  other  untrack- 
able  signals  need  to  be  developed 
and  made  available. 

The  practical  difference  in 


effect  upon  CMA  of  dropping  or 
inhibiting  trackers  could  not  be 
determined  (problem  22a) .  Guide¬ 
lines.  for  selecting  the  appropriate 
action  should  be  made  available. 

Sonarmen  are  not  particularly 
well  versed  in  conventional  CMA 
techniques  and  the  ISPE  CMA  function 
is  very  sophisticated  and  in  some 
cases  allows  the  operator  a  choice 
of  several  inputs.  Effective  use 
of  these  options  will  require 
detailed  knowledge  of  their  effects 
and  the  subtle  distinctions  among 
these  effects  (problems  22a  and  b) . 
This  is  one  of  the  few  instances 
where  lack  of  detailed  knowledge 
of  the  algorithms  employed  by 
the  system  may  lead  to  degradation 
of  performance. 

Experienced  operators  believe  they 
can  detect  contact  maneuvers  and 
frequently  differentiate  between  a 
target  zig  or  a  speed  change  almost 
instantaneously  on  the  basis  of 
displayed  sonar  information.  In 
cases  where  the  operator  is 
actively  tracking  a  target,  it  is 
likely  that  he  will  be  able  to 
detect  and  name  the  kind  of  maneuver 
executed  by  the  contact  more 
rapidly  than  the  system's  automatic 
processing  algorithms.  Guidance  as 
to  the  best  way  of  constraining 
the  system  solution  in  response 
to  specific  information  developed 
by  the  operator  is  required 
(problem  22c) . 

In  the  scenarios  created  for 
this  study,  sonar  threat  alerts 
occurred  at  both  the  search  and 
class-loc  consoles.  Class-loc 
operators  were  of  the  opinion  that 
someone  else,  either  the  search 
operator  or  the  supervisor,  should 
be  tasked  with  responding  to  sonar 
threats, especially  in  situations 
where  they  were  actively  engaged 
in  tracking  a  contact.  Clear 
allocation  of  responsibility  for 
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Table  7,  Miscellaneous  Problems 


Problem  Problem  Description 

19  (1/1)  Pushed  "enter 
computed  range "  twice 
upon  completion  of  MPR; 
effect  on  machine  process¬ 
ing  uncertain, 

20  (2/2)  Difficulty  in  dealing 
with  tracker  captured  by  the 
louder  of  two  crossing 
contacts . 

21  (2/2)  Transients.  How  to 
enter  information  on 
transients  to  the  system 
needs  clarification. 

22a  (1/1)  Uncertain  of 

differences  in  effect  upon 
CMA  of  dropping  or  inhibiting 
trackers. 

22b  (3/3)  Unsure  of  difference 
in  effect  upon  CMA  of 
"enter  computed  range" 

(2. 7. 6. 1-8)  on  MPR  tier 
and  "enter  range"  (2. 7. 6. 1,2-0) 
on  CMA  tier. 

22c  (2/2)  Detects  speed  change 
in  grams,  unsure  of  whether 
to  "enter  speed"  (2 .7 .6. 1. 2-3) 
or  "enter  speed"  and 
"maneuver  detect"  (2. 7. 6. 1.2-5) 
"detect  speed  change" 

(2. 7. 6. 1.3-4) . 

23  (2/2)  Class-loc  operator  says 
"sonar  threat"  responses 

are  a  distraction  at  his 
console,  and  should  be 
handled  by  someone  else. 

24  (1/1)  Position  (Class-Loc  or 
Supervisor) responsible  for 

data  entry  via  CM  needs  to  be 
determined. 


Solution  Proposed 

Designers  should  protect  against 
spurious  entries. 


A  procedure  needs  to  be  established 
and  trained. 


Need  guidelines  for  dealing  with 
transients  and  the  untrackable 
signals. 

Guidance  required  as  to  exact 
effect  of  available  alternatives 
and  when  each  should  be  used. 


Clear  allocation  of  responsibility 
is  desirable. 


Clear  allocation  of  responsibility 
is  desirable. 
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handling  sonar  threats  is 
desirable.  Consideration  should 
be  given  to  allowing  the  "sonar 
threat"  function  to  be  disabled 
at  selected  consoles. 

Some  subjects  spent  a  great 
deal  of  time  entering  classification 
information  to  the  Class-Menu 
Display  (problem  25) ,  Jt  was 
suggested  that  entry  of  this 
information  to  the  system’s 
records  should  be  done  by  the 
supervisor.  Again,  guidelines 
allocating  responsibility  for 
various  functions  are  desirable. 

Comments 

Subject  comments  and  the 
experimenters '  observations  were 
recorded  throughout  the  execution 
of  the  scenarios  and  in  the 
debriefing  session  at  the 
conclusion  of  the  experiment. 
Selected  comments  are  presented 
in  Table  8  (overleaf) .  These 
fall  into  3  categories: 
reservations  about  system  operation, 
suggestions,  and  praise.  The 
letter  following  the  comment 
indicates  the  subject  who  made  it. 
Comments  which  were  either  trivial, 
or  reflected  an  inadequate  under¬ 
standing  of  the  system  have  been 
omitted.-  while  it  is  not 
proposed  that  the  system  be 
modified  in  light  of  these 
reservations  and  suggestions,  the 
authors  do  concur  in  the  majority 
of  the  comments. 

Discussion 

1.  Operability.  This  study 
was  limited  to  an  assessment  of 
the  operability  of  those  features 
available  to  operators  on  the 
search  and  class -loc  consoles. 
Subjects  operating  these  consoles 
experienced  little  difficulty  in 
responding  to  the  events  presented 
in  the  two  scenarios.  At  no  point 


did  the  logic  Of  the  control 
structure  interfere  with  their 
prosecution  of  the  contacts 
presented.  It  is  concluded 
that  the  operability  of  those 
parts  of  the  control  structure 
which  were  tested  is  entirely 
satisfactory. 

There  is  room  for  improvement 
in  the  implementation  of  some 
functions ,  however .  The  present 
control  structure  for  the  search 
and  ciass-loc  functions  is 
seriously  deficient  in  only  two 
respects:  1)  it  is  entirely  too 

easy  for  the  operator  to  mix  the 
data  from  two  contacts  in  one 
file  (problem  1);  and  2)  the 
controls  available  for  responding 
to  threat  alerts  could  be 
considerably  improved  (see 
discussion  of  problem  4) .  The 
proposed  modifications  to  the 
threat  alert  response  tiers 
would:  a)  bring  the  logic  of 
these  controls  more  into  line 
with. that  of  similar  controls 
elsewhere  in  the  system;  and  b) 
enhance  the  speed  and  flexibility 
of  response  to  such  alerts.  The 
rest  of  the  modifications 
proposed  as  solutions  to  problems 
encountered  should  make  the 
system  easier  to  deal  with  for 
the  inexperienced  operator. 

2.  Training.  Almost  everything 
about  ISPE  was  new  to  the  subjects, 
many  of  whom  were  from  boats  that 
had  just  received  the  AN/BQR-21. 

The  major  problems  encountered 
were  those  related  to  aspects  of 
ISPE  operation  that  had  no  counter¬ 
part  in  the  experience  of  our 
subjects.  A  primary  example  is  the 
importance  of  the  distinction 
between  hooked  and  unhooked  modes 
of  operation.  Most  of  the  problems 
related  to  hooked  contacts  could 
be  avoided  if  operators  were 
instructed  to  hook  a  contact  only 
when  dealing  actively  with  it  and 
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Reservations; 


Tahle  8,  Selected  Comments 


1.  "Entering  the  'predominant  signal'  to  Class  Menu  for  most  routine 
contacts  is  a  nuisance,  99  or  98%  are  all  the  same,"  C, 

2.  Subject  doesn't  like  the  idea  of  DLS  displays  to  Conn:  "too  many 
[routine  DlJ  signals  vri.ll  cause  unnecessary  talk  from  Conn  to 
sonar . ”  E . 

3.  "Detection  prediction  ...  it's  never  going  to  be  right  anyway  -  just 
going  to  give  the  OOD  something  to  worry  about  that  he  doesn’t 
need  to"  OOP’s  do  not  appreciate  how  approximate  the  range  of  the 
day  is:  they  tend  to  think  sonar  is  malfunctioning  or  goofing-off 
if  every  contact  is. not  detected  at  the  predicted  range.  D. 

Similar  comment  by  E. 

4.  Re  experience  with  BQR-21:  "I  hope  ISPE  is  fairly  fast  about 
hooking  and  unhooking . "  D . 

Suggestions: 

5.  "The  whole  business  of  controlling  CMA  might  best  be  done  on  GeoSit 
or  even  a  separate,  dedicated  display."  D.  Similar  comment  by  A. 

6.  Re  assignment  of  classification  channels  on  the  Class-Summary 

Display:  "Assign  class  channels  on  the  display  that  deals  with 

these,  not  on  C-S."  C. 

7.  "In  the  Contact  Status  Log  section,  the  Sierra  number  should  be  on 
the  left,  not  the  file  number,  and  the  tracker  table  should  list 
Sierra  numbers  instead  of  the  file  numbers."  E. 

8.  "The  Contact  Status  Display  should  be  visible  all  the  time  -  maybe  a 
separate  repeater  for  this,  visible  from  all  three  consoles."  E. 

9.  Pressing  "compute  ratio"  after  "mark  #2"  on  ratio  compute  tiers  is 
an  unnecessary  extra  step  -  could  be  done  automatically  when  second 
line  is  marked.  A. 

Praise: 

.  10.  "Being  a  search  operator  would  be  easy  to  do.  You  could  train 
anybody."  G,  Similar  comment  by  H, 

11.  "That  Geographic  Situation  i-  boy  is  that  going  to  help  me  out  at  sea 
That's  going  to  be  a  life saver."  C.  Subject  says  he  has  trouble 
with  plots,  visualizing  the  'big  picture.'  Similar  comment  by  D. 

12.  CMA  update  function  will  be  "good  because  it  will  teach  new  people 
what  affects  the  CMA  solution."  E. 


to  always  drop  hook  when  they 
finished  a  particular  operation. 

Although  certainly  not 
difficult,  the  system  of 
assigning  files  to  individual 
contacts  and  then  accessing  those 
files  in  order  to  record  information 
or  assign  additional  resources  for 
the  prosecution  of  the  contact 
needs  to  be  thoroughly  mastered. 

The  ease  with  which  spurious 
files  can  be  created  or  data 
entered  to  the  wrong  file 
requires  that  the  system  be 
operated  very  deliberately,  and 
that  the  operator  at  all  times  be 
conscious  of  the  files  associated 
with  each  contact. 

The  concept  of  resource 
allocation  should  also  be  stressed. 
Again,  the  concept  is  not 
difficult  but  it  takes  a  while 
for  operators  of  older  systems 
to  get  used  to  assigning 
correlation  or  classification 
channels  to  a  particular  contact 
instead  of  simply  using  one 
basic  resource  with  which  to 
prosecute  all  contacts. 

The  system  functions  of 
continuous  contact  motion  analysis 
and  multipath  ranging  also  were  new 
to  our  Subjects.  The  concepts  are 
not  new  to  sonarmen,  although  most 
have  not  had  experience  with 
systems  having  these  capabilities. 
The  CMA  function  should  be 
emphasized  in  training,  as  sonarmen 
are  not  particularly  well  versed 
in  conventional  CMA  techniques  and 
the  ISPE  CMA  functions  allow  the 
operator  a  choice  of  several 
different  input  s . 

The  multifunction  switching 
system  employed  in  the  control 
structure  is  in  general  well 
thought  out  and  appeared  to  be 
quite  easy  to  learn.  On  one  level, 
the  control  structure  is  very 


flexible,  but  on  another, it  is  very 
rigid.  Prosecution  of  a  single 
contact  requires  the  execution  of 
a  number  of  logically  distinct 
actions  (data  entry  sequences) .  This 
system  is  very  flexible  in  that  the 
order  of  these  sequences  is  largely 
left  up  to  the  operator.  However, 
it  is  inflexible  in  regard  to  the 
execution  of  the  data  entry 
sequences,  which  must  be  completed 
(or  aborted)  before  the  operator  is 
free  to  do  much  of  anything  else. 

Such  is  generally  not  the  case  with 
less  automated  systems.  The 
necessity  of  completing  a  sequence 
once  initiated  should  be  emphasized. 
Training  should  also  emphasize 
methods  of  graceful  recovery  from 
actions  initiated  by  error.  It  is 
also  axiomatic  that  operators  should 
be  thoroughly  familiar  with  the 
options  available,  how  they  are 
related  to  other  options  (especially 
in  regard  to  those  which  are 
mutually  exclusive) ,  and  the  paths 
from  one  part  of  the  control 
structure  to  the  next. 

3 .  Evaluation .  In  general, 
the  controls  associated  with  the 
search  and  class-loc  displays  are 
well  thought  out  and  logically 
implemented.  Subjects  in  the 
experiment  appeared  to  have  very 
little  difficulty  in  learning  to 
use  the  control  structure  with  a 
high  degree  of  fluency  and  flexibility. 
With  the  exception  of  those  awkwardly 
implemented  features  previously 
noted ,  the  system  appears  to  exhibit 
no  major  operability  problems. 

The  sonarmen  participating  in 
this  experiment  were  generally  quite 
impressed  with  the  capability  of  the 
system  as  it  was  explained  to  them. 
They  accepted  it  readily  and  for  the 
most  part  enthusiastically.  We 
believe  their  enthusiasm  was  well 
founded . 
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Footnotes 

1.  Development  of  ISPE  as  an 
integrated  sonar  suite  was  sus¬ 
pended  in  December  of  1980.  The 
technology  developed  for  ISPE 
survives  as  Towed  Array  Signal 
Processing  Equipment  (TASPE) , 
which  will  employ  a  single  ISOD 
having  Broad  Band,  "Difar-Like" 
and  Class-Analysis  displays.  The 
first  TASPE  units  are  to  be 
deployed  in  fiscal  1985. 

2.  Reducing  the  number  of  spaces 
available  for  the  writing  of  control 
labels  necessitated  the  abbreviation 
of  some  terms  that  are  not 
abbreviated  in  the  actual  system 
and  the  further  shortening  of  some 


existing  abbreviations.  Shortening 
was  generally  accomplished  according 
to  the  "contraction-vowels .  out” ' 
rule.  Although  no  formal  attempt 
was  made  to  eyaluate  it,  shortening 
did  not  appear  to  affect  the 
interpretability  of  the  labels. 

Many  of  the  problems  identified  in 
this  report  are  traced  to  wording 
of  particular  control  labels.  In 
some  cases,  shortening  may  have 
reduced  the  legibility  of  a  label, 
but  the  problems  identified  are 
semantic  and  may  not  be  attributed 
to  the  abbreviations. 

3 .  Unhooking  upon  completion  of  an 
operation  was  emphasized  in  the 
"Common  Procedures"  training  handout 
All  control  sequences  requiring 
hooking  were  concluded  with 
activation  of  FAB  10,  "Release  Hook. 
Even  with  this  emphasis,  failure 

to  drop  hook  was  a  common  problem 
among  our  inexperienced  operators. 
Although  failure  to  drop  hook 
should  not  be  a  problem  for 
experienced  operators,  it  should  be 
remembered  that  a  significant 
proportion  of  operators  will  be 
inexperienced,  and  many  will  come  to 
the  system  without  formal  training 
in  its  operation. 

4.  To  avoid  the  use  of  classified 
terminology,  the  names  for  functions 
and  VAB  labels  used  in  this  paper 
are  those  of  the  NUSC  "Button  Tree" 
program. 

5.  When  the  ISOD  is  configured  to 
present  both  BB  and  DL  displays,  the 
bearing  cursors  on  the  two  displays 
are  slaved.  Examination  of  the  DL 
display  before  activating  "new  trace 
at  bearing"  is  greatly  facilitated 
by  this  feature,  and  should  be  done 
routinely  before  signaling  a  new 
contact.  However,  overlooking  a 
relatively  weak  contact,  especially 
if  there  are  a  number  of  other, 
stronger  signals  on  the  display. 
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remains  a  possibility,  especially 
in  the  case  of  the  inexperienced 
operator , 

6.  Correlation  channels  may  be 
released  through  the  Class-Analysis 
Display  (VAB  2, 7. 6,1-4),  but 
classification  channels,  while 
they  may  be  reassigned  through  the 
Class-Summary  Display,  may  be 
released  only  via  the  Contact 
Status  Display, 
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APPENDIX  A 


SCENARIOS  USED  IN  OPERABILITY  EVALUATION 


SCENARIOS  USED  IN  OPERABILITY  EVALUATION 

The  scenarios  presented  in  this  appendix  represent  two  segments  of 
routine  FBM  patrofs.  There  ate  tw  written  scenarios  for  each  segment, 
one  describing  events  as  they  would  be  presented  to  an  operator  running 
the  search  console  and  one  describing  the  same  eyents  as  they  would  be 
presented  to  a  man  serying  as  the  class-loc  operator.  No  attempt  has  been 
made  to  model  the  anticipated  detection  performance  of  the  system,  but  we 
did  try  to  include  a  variety  of  contacts  and  common  occurrences,  such  as 
transients,  contacts  that  shut  down  and  start  up  again,  and  maneuvers  by 
both  the  contacts  and  own  ship. 

The  displays  were  represented  by  line  drawings  (on  35  mm  slides)  taken 
from  the  FOD.  No  attempt  was  made  to  simulate  displayed  data.  Rather, 
the  subject  was  told  by  the  person  reading  the  scenario  what  was  being 
displayed. 

Each  scenario  was  presented  as  a  series  of  discrete  events.  These  are 
numbered  as  El,  E2,  etc.  Below  the  event  number  is  the  time  in  the  problem 
when  the  event  would  have  occurred,  had  the  scenarios  been  happening  in  real 
time.  The  scenario  was  presented  in  terms  of  four  kinds  of  information, 
indicated  by  abbreviations  in  the  text: 

SI:  (Sonar  Indication)  information  being  displayed,  e.g.,  "Dimus  trace 

at  072°T . " 

E:  (Event),  e.g.,  "Search  operator  reports  BB  contact  at  072°T,  1 

tracker  in  ATF . " 

D:  (Direction),  e.g.,  "Supervisor  wants  a  second  tracker  on  the 

towed  array. " 

P:  (Prompt),  e.g.,  "remember  standard  operating  procedure  (re  MPR) . " 

A  fifth  abbreviation  appears  in  the  text:  RA  (for  reader  action) .  This  is 
to  remind  the  reader  to  change  a  card  which  duplicated  the  own-ship  readout 
at  the  top  of  the  displays.  These  cards  were  changed  whenever  own  ship 
changed  course  or  speed. 
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SCENARIO  #1A 


A.  GENERAL  INFORMATION 

1.  On  routine  patrol,  west  Atlantic  basin 

2.  Sea  State  1-2 

3.  Water  Depth  1500  Fathoms 

4.  Layer  at  165  feet 

5.  No  Convergence  Zone 

6.  Own  ship  depth  140  feet 

7.  Own  ship  speed  6  knots  on  course  300° 

8.  Towed  array  scope  1800  feet 

B .  INTELLIGENCE  REPORT 

1.  Type  II  or  III  to  Southwest 

2.  Normal  merchant/trawler  shipping 

3.  US  Warship  in  area,  with  SQS  26 (A)/3 . 5-3 . 7  Khz 

C.  CURRENT  SITUATION: 

1.  Crossing  shipping  lane,  2  contacts  held: 

(a)  one  at  129°,  drawing  left,  past  CPA  and  opening:  S-141, 

(b)  one  at  254°,  drawing  right  (to  cross  bow  at  16,000  yds): 
Class  M, 

D.  ISPE  PRESENTLY  CONFIGURED: 

1.  Conformal  array  is  DL  sensor 

2 .  Broad  Band  Search  with  cylinder  and  towed  array 

E.  SONAR  STANDARD  OPERATING  PROCEDURES: 

1.  Triangulate  contacts  where  geometry  and  resources  permit 

2.  Do  Multi-Path  Ranging  on  all  contacts  in  bow  quadrant 
(MPR  only  works  with  BB  contacts) 

3.  Broad  Band  range  of  the  day  is  39  kyds 


Class  M. 
S-142 , 
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SCENARIO  1A,  SEARCH 


E  0 
T  0 


E  1 
T  5 

E  2 
T  IS 


E  3 
T  22 

E  4 
T  32 


E  5 
T  35 


E  6 
T  40 

E  7 
T  40 

E  8 
T  43 


E  9 
T  45 


E  10 
T  46 


E  11 
T  50 

E  12 
T  63 


RA:  Rut  up  OS  Card  1A.  OS  Co  300°  So  6  kts 
P:  Hold  2  contacts,  both  classified  as  merchants. 

A.  S-141,  directly  behind  at  129°,  1  tracker  in  ATF  on  towed 
array 

B,  S-142,  at  254°,  drawing  towards  bow,  2  trackers  in  ATE, 
one  on  cylinder  and  one  on  towed  array. 

SI:  New  line  on  FRAZ,  363  Hz,  Stable  (will  track  in  ATF)  316° 

D:  Supervisor  designates  Sierra  143. 

SI:  Notices  BB  trace  on  cylinder  ITA/LTA  at  the  same  bearing  as 

S-143  (now  310°)  (will  not  track  in  ATF  yet) 

P:  Notice  trace  is  stronger  on  the  towed  array.  (Will  track  on 
towed  in  ATF . ) 

E;  Class  Operator  reports  S-143  is  US  Frigate  1068  Class,  two  4- 
bladed  screws  making  192  rpm  (24  kts)  . 

SI:  DIMUS  trace  from  S-141  fades  from  towed  array  ITA/LTA.  Notice 
tracker  symbol  not  tracking. 

D:  Supervisor  says  to  drop  track. 

SI:  Detect  new  line  while  paging  through  LOFAR:  301  Hz,  194°. 

Will  not  track  in  ATF. 

D:  Supervisor  designates  Sierra  144. 

SI:  Threat  alert  at  301  Hz  (Sierra  144) .  301  Hz  is  strong  enough 

to  track  in  ATF. 

E:  Own  ship  turns  to  course  270°. 

RA:  Put  up  OS  Card  IB. 

SI:  Threat  alert  from  another  line  at  294  Hz  on  S-144 
D:  Supervisor  wants  a  tracker  on  line.  Supervisor  tells  Class 
Operator  to  take  over  monitoring  of  S-144. 

SI:.  Notice  that  S-143  DIMUS  trace  has  2  tracker  symbols  with  it, 
S-142  trace  (which  is  weaker)  has  none. 

P:  Supervisor  will  want  that  straightened  out. 

SI:  New  trace  on  towed  array  ITA  111/249°R.  Nothing  on  cylinder. 
D:  Brings  BQR-7  on  BB  left  to  resolve  bearing.  Designates 

Sierra  145.  Restores  cylinder  after  bearing  resolved. 

E:  Own  Ship  turning  to  180°, 

RA:  Put  up  OS  Card  1C. 

E:  Own  Ship  turning  to  270°. 

RA:  Put  up  OS  Card  ID. 
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D: 
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Very  bright  spots  on  S-143  trace  at  232°,  Spots  are  appropriate 
to  1068  Class's  sonars. 

Yon  can  hear  echo -rang ing , 

Supervisor  tells  Search  Operator  to  monitor  S-143. 

Class  Operator  reports  S-144  possible  Type  II,  and  appears 
to  be  slowing. 

Class  Operator  reports  up-doppler  from  S-144,  Own  Ship  turns 
to  300°,  increase  speed  to  10  kts. 

Supervisor  informs  Search  Operator  that  now  DL  sensor  is  towed 
array.  Directs  search  operator  to  replace  towed  array  with 
conformal  on  BB, 

Put  up  OS  Card  IE. 

Another  series  of  bright  spots  from  S-143. 

You  can  hear  him  echo -ranging  again. 

ITA  trace  on  cylinder,  330°. 

Supervisor  designates  at  S-146. 

S-146  is  directly  ahead  of  you. 

Trace  from  S-143  fades  on  ITA. 

Maybe  he's  out  of  range. 

Supervisor  says  to  drop  tracker  if  out  of  range. 


END  OF  PROBLEM 
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SCENARIO  1A,  CIASS-LOC 

Put  up  OS  Card  1A. 

Hold  2  contacts,  both  classified  as  merchants, 

A.  S-141,  directly  behind  at  129°T,  1  tracker  in  ATF  on 
towed  array, 

B.  S-142,  at  254°,  drawing  towards  bow,  2  trackers  in  ATF, 
one  on  cylinder  and  one  on  towed  array.  One  correlation 
channel  assigned. 

Search  operator  reports  new  line  on  FRAZ,  363  Hz,  316°T.  He 

has  one  tracker  in  ATF. 

Supervisor  designates  Sierra  143, 

Only  this  one  good  line  so  far. 

More  lines  are  beginning  to  show  on  LOFAR. 


Search  operator  reports  he  now  holds  S-143  broad  band,  one 
tracker  in  ATF  on  the  towed  array 

You  now  have  enough  lines  to  get  a  good  match  with  a  file 
signature  (US  Frigate  1068  class) . 

DEMON  shows  two  4-bladed  screws  making  192  rpm  (24  kts) . 
CMA  gives  20  kts. 

Search  Operator  drops  track  on  S-141. 


Search  Operator  reports  a  line  on  LOFAR  at  301  Hz,  194°.  Not 
strong  enough  to  track  in  ATF. 

Supervisor  designates  Sierra  144. 

Search  Operator  has  assigned  a  tracker  to  the  301  Hz  line  in 
ATF. 

Own  Ship  turns  to  course  270° . 

Put  up  OS  Card  IB. 

Threat  alert  from  another  line  (294  Hz)  on  S-144. 

Supervisor  tells  Class  Operator  to  take  over  prosecution  of 
S-144.  He  wants  another  tracker  on  this  line. 

Supervisor  tells  Search  Operator  to  monitor  S-143  and  report 
any  signs  of  a  maneuver. 

More  lines  are  coming  up  on  S-144  LOFAR 


Search  Operator  reports  new  BB  contact  at  021° ,  Two  trackers 
in  ATF  (towed  and  conformal) . 

Supervisor  designates  Sierra  145. 
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E:  Own  Ship  turning  to  course  180°. 

RA;  Put  up  OS  Card  1C. 

SI;  Threat  alert  from  S-144  (from  line  already  seen  on  LOFAR) . 

D;  Superyisor  requires  a  tracker  on  that  line* 

SI;  Signature  lines  match  Type  II  reference  signature  (if  still 
working  on  signature) * 

P:  (if  not  working  on  it)  How  are  you  coining  on  classification  of 

S-144? 

SI:  One  line  is  a  known  propulsion  line,  another  is  a  known 
auxiliary. 

SI:  DEMON  from  S-145  shows  one  4-bladed  screw  at  170  rpm. 

P:  Probable  light  craft,  possible  trawler. 

E:  Own  Ship  turning  to  course  270°. 

RA:  Put  up  OS  Card  ID. 

SI:  Down  doppler  on  S-144,  up  doppler  on  S-143. 

SI:  DEMON  from  S-143  shifting  to  lower  frequencies.  May  also 
notice  slight  up  doppler  on  LOFAR  (if  watching) . 

SI:  (if  takes  turn  count)  shaft  rate  now  85  rpm. 

P:  That's  about  10  kts. 

E:  Search  Operator  reports  echo-ranging  from  S-143. 


SI;  S-144  lines  show  slight  down  doppler,  decreasing  SNR. 
Propulsion  line  shifts  to  lower  frequency. 

D:  Supervisor  tells  Class  Operator  to  reassign  trackers  on 

S-144s  strongest  lines  to  towed  array. 

E:  Own  Ship  turns  to  course  300°,  increases  speed  to  10  kts. 

SI:  S-144  lines  on  LOFAR  waver,  but  show  very  little  change. 

RA:  Put  up  OS  Card  IE. 

E:  Search  Operator  reports  more  echo-ranging  from  S-143. 

E:  Search  Operator  reports  new  contact  at  333°,  drawing  left,  has 

1  tracker  in  ATF. 

P:  That  is  almost  right  in  front  of  you. 

D:  Supervisor  designates  Sierra  146. 

P;  (After  MPR)  range  is  33  kyds. 

SI:  Threat  alert  from' S-144.  (from  a  line  already  in  file) 

P:  If  that  is  an  old  line,  why  did  it  suddenly  cause  a  new  alert? 
SI:  Slight  up  doppler,  propulsion  lines  increasing  in  frequency, 

two  new  lines. 

P:  S-144  has  changed  course. 
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SI:  EOFAR  frcun  S~143  shows  new  lines,  down  doppler ,  DEMON  shows 
shaft  rate  increasing  to  185  rpm. 

E;  Own  Ship  turns  to  course  330° . 

SI;  Down  doppler  on  S-144,  S-143, 

RA:  Put  up  OS  Card  IF. 

E:  Supervisor  has  changed  DD  sensor  to  towed  array. 

D;  Supervisor  requests  classification  of  S-146. 

SI:  DEMON  shows  on  4-bladed  screw  making  62  rpm  -  Probable  Merchant. 


END  OF  PROBLEM 
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SCENARIO  #2’ 


A.  GENERAL  INFORMATION: 

1,  On  routine  patrol  in  North  Atlantic  off  the  UK  Gap 
2*  Sea  State  3-4  (on  10  point  scale) 

3,  Water  Depth  800  Fathoms 

4,  Layer  at  240  feet 
5»  No  convergence  zone 

6.  Own  ship  depth  140  feet 

7.  Own  ship  speed  6  knots  on  course  030° 

8.  Towed  array  cable  scope  1800  feet 

B.  '  INTELLIGENCE  REPORT: 

1.  Normal  merchant/trawler  shipping 

2.  Type  II  reported  North/Northwest 

C.  CURRENT  SITUATION: 

1.  No  shipping  held 

2.  Large  number  of  biologicals  to  East  and  Northeast 

D.  ISPE  PRESENTLY  CONFIGURED: 

1.  Conformal  array  is  in  the  DL  sensor 

2.  Broad  Band  Search  with  cylinder  and  towed  array 

E.  SONAR  STANDARD  OPERATING  PROCEDURES: 

1.  Triangulate  contacts  where  geometry  and  resources  permit 

2.  Do  Multi-Path  Ranging  on  all  contacts  in  bow  quadrant 
(MPR  only  works  with  BB  contacts) 

3.  Broad. Band  range  of  the  day  is  30  kyds 
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SCENARIO  2,  SEARCH 


IS  0 
T  0 

E  1 
T  1 


E  2 
T  4 


E  3 
T  5 


E  4 
T  8 


E  5 
T  10 


E  6 
T  12 

E  7 
T  16 

E  8 
T  20 


E  9 
T  21 


E  10 
T  22 


E  11 
T  25 


RA:  Put  up  OS  Card  2A. 

SI;  New  line  on  FRAZ  at  318°  (302  Hz,  broad,  diffuse  and  unstable) . 
(will  track  in  ATF) 

D;  Supervisor  designates  as  sierra  131. 

P:  Remember  Standard  Operating  Procedures, 

SI:  DIMUS  trace  on  left  at  098°,  on  right  at  068/292°R 
(corresponding  relative  bearings) .  Can  hear  it. 

D:  Supervisor  designates  as  Sierra  132. 

SI:  Weak  DIMUS  trace  on  LTA  of  towed  array  078/282°R.  Not  able 
to  hear  it,  not  enough  SNR  to  track  in  ATP. 

D:  Supervisor  directs  replace  cylindrical  array  with  conformal 

array  to  resolve  bearings.  (Low  SNR  there  too  Bearing 
312 °T  is  the  same  as  S-131  on  DL. 

P:  Supervisor  prefers  you  restore  cylinder  because  of  better 
frequency  response. 

SI:  DIMUS  trace  on  left  at  073°,  on  right  at  043/317°R 
(corresponding  relative  bearings) .  Can  hear  it. 

D:  Supervisor  designates  Sierra  133. 

SI:  Intermittent  trace  on  cylinder  STA  044°. 

SI:  Sounds  like  winch  noises. 

D:  Supervisor  designates  as  Sierra  134. 

SI:  DIMUS  trace  from  S-131  now  in  towed  ITA  fields  -  still  can't 
hear  it.  (ATF  trackers  will  lock) 

SI:  DIMUS  trace  in  ITA  field  of  left  display.  047°.  Can  hear  it. 

D:  This  is  probably  S-134. 

SI:  New  line  on  FRAZ,-  301  Hz,  312°.  (S-131  is  at  255°  now)  Line 

strong  enough  to  track. 

D:  Supervisor  designates  as  Sierra  135. 

SI:  DIMUS  traces  from  S-133  weaken  and  end  abruptly.  Can  no  longer 

hear  it  100°T. 

D:  Supervisor  says  not  to  drop  file. 

SI:  Threat  alert:  301  Hz,  313°.  (Line  is  already  in  file  for  S-135) 

D:  Supervisor  tells  Search  Operator  to  acknowledge,  then  to 

continue  to  watch  S-135  while  Class-Loc  works  on  identification. 

D:  Supervisor  wants  a  second  tracker  on  the  towed  array. 

E:  Own  Ship  turns  to  course  000°  (to  avoid  trawlers  to  Northeast) . 

RA:  Put  up  OS  Card  2B. 

SI:  DIMUS  from  S-132  stops  124°. 
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T  70 


SI:  New  trace  on  towed  array  058/302°R,  (same  bearing  as  S-134) 

D;  Superyisor  tells  to  assign  tracker  on  towed  to  triangulate* 

S J ;  Strong  transient  (eyenon  cylinder  STA-  if  cylinder  is  still 
being  displayed)  from  Sol34, 

E:  lines  from  S-135  decreasing  in  SNR;  lost  ATF , 

D;  Supervisor  directs  Search  Operator  to  track  S-135  in  MTB. 

E:  Own  Ship  turns  to  course  270°, 

RA:  Put  up  OS  Card  2C, 

E:  Towed  array  stabilized  after  turn. 

SI:  S-134  trace  on  towed  array  stops  abruptly  at  072°. 

(S-134  is  in  baffles  for  hull  arrays) 

SI:  Spaced  bright  transient  on  towed  array  STA  at  073°.  Hears 
noises  from  S-134. 

D:  Supervisor  tells  not  to  drop  file. 

SI:  While  paging  LOFARs,  notices  increasing  SNR  from  S-135. 

Pr  MTB  tracker  can  go  to  ATF  now. 

E:  Threat  alert  from  S-135:  300  Hz,  331°  (same  line  as  first 

threat  alert) .  (Threat  gram  indicates  tracker  already  assigned) 

E:  Another  threat  alert  from  S-135.  New  frequency. 

D:  Supervisor  requests  a  tracker  on  the  towed  array  for  this  line. 

SI:  New  DIMUS  trace  on  cylinder  (or  conformal)  at  130° ,  on  towed  at 
140/220°R.  Can  hear  it. 

P:  This  is  about  the  same  place  S-132  stopped. 

D:  Supervisor  asks  what  it  sounds  like.  (It  sounds  like  S-132) 

D:  Supervisor  says  to  enter  to  S-132  file. 

SI:  New  BB  trace  on  towed  array  ITA  157/203°R.  (113°T  is  in 
baffles  of  hull  arrays) 

P:  This  is  about  the  same  place  S-133  stopped. 

D:  Supervisor  asks  what  it  sounds  like.  (Can't  hear  it) 

P:  Are  you  listening  to  the  same  array  you  see  it  on?  (It  sounds 
like  S-133) 

D:  Supervisor  says  to  enter  to  S-133  file. 

SI:  Notice  that  tracker  symbols  for  S-132  and  S-133  are  both  on 
one  trace  (i.e,,  the  louder  has  captured  the  weaker). 


END  OF  PROBLEM 
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RA;  Put  up  OS  Card  2A. 


E:  Search  Operator  has  assigned  1  tracker  to  an  unstable  302  Hz 

line.  318°. 

D:  Supervisor  designates  Sierra  131. 

P:  Must  now  wait  3  or  4  minutes  for  grams  to  develop  <-  in  that 
time  other  things  happen. 

E:  Search  Operator  reports  new  contact  at  098°,  has  2/  trackers 
in  ATF . 

D:  Supervisor  designates  Sierra  132. 

P:  Contact  abeam  and  drawing  aft  -  multi-path  ranging  (MPR)  Not 
required  at  this  time. 

SI:  Now  have  usable  DEMON  on  S-132. 

P:  One  4-bladed  screw,  90  rpm,  sounds  like  sometimes  out  of  water. 
(Classified  as  probable  trawler) 

E:  Search  Operator  reports  new  contact  at  073° ,  has  2  trackers 

in  ATF. 

D:  Supervisor  designates  Sierra  133. 

E:  Search  Operator  reports  possible  winch  noises  at  .044°. 


E:  Search  Operator  reports  BB  trackers  in  ATF  on  S-131. 


SI:  Now  have  usable  DEMON  on  S-133. 

P:  One  3~bladed  screw  making  200  rpm  (Classed  as  light  craft: 

trawler) . 

E:  Search  Operator  has  new  contact  at  047°.  One  tracker  in  ATF. 

D:  Supervisor  designates  Sierra  134. 

P:  S-134  is  almost  dead  ahead  of  you. 

SI:  Have  usable  DEMON  On  S-131. 

P:  One  4-bladed  screw  making  108  rpm,  that  plus  multiple  wavering 
lines  (classed  as  probable  merchant) . 

E:  Search  Operator  reports  new  line  on  FRAZ,  301  Hz,  312°,  Has 

assigned  2  trackers  in  ATF. 

D:  Supervisor  designates  Sierra  135. 

E:  Search  operator  reports  S-133  disappeared. 

E:  Threat  alert.  301  Hz,  313°. 

P:  This  line  is  already  on  file. 

D:  Supervisor  tells  Class-Loc  Operator  to  take  over  tracking  of  S-135 
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E  13  SI;  Have  usable  DEMON  on  SAL34. 

T  23  P:  One  4-bladed  screw  making  165  rpro.  (Classed  as  light  craft: 

trawler) 

E  14  E:  Own  ship  turns  to  course  000°. 

T  25  RA:  Put  up  OS  Card  2B, 

E  15  E;  Search  Operator  reports  ping  from  S^134. 

T  31 

E  16  SI;  Additional  lines  beginning  to  come  in  on  SKL35  gran)  -  seems 
T  32  stable. 

P:  Beginning  to  look  as  though  he  might  be  the  Type  II. 

E  17  SI;  Lines  from  S-135  decreasing  in  SNR  (tracker  beginning  to  unlock) . 

T  34  D:  Supervisor  orders  search  operator  to  MTB  300  Hz  tracker. 

E  18  E:  Own  Ship  changes  course  to '270°. 

T  37  RA:  Put  up  OS  Card  2C. 

E  19  SI:  Notices  slight  up-doppler  as  OS  swings  bow  past  S-135  (now  at 

T  39  324)  . 

P:  Possibly  due  to  own  ship  motion. 

E  20  E:  Towed  array  stabilized. 

T  43 

E  21  E:  Search  Operator  reports  S-134  stopped. 

T  44 

E  22  E:  Search  Operator  reports  echo-ranging  from  073°. 

T  45 

E  23  SI:  New  lines  appearing  on  S-135  grams,  getting  stronger:  slight 
T  47  up-doppler,  propulsion  lines  increasing  in  frequency. 

E:  Search  Operator  puts  tracker  back  in  ATF . 

E  24  E:  Threat  alert  from  S-135:  301  Hz,  331°.  (This  is  a  reactiv- 

T  48  ation  of  a  previous  alert) 

SI:  Additional  lines  appearing. 

E  25  E:  Another  threat  alert  from  S-135  (new  line). 

T  49  D:  Supervisor  requests  restore  trackers  on  towed  array  (in 

preparation  for  turning  away  from  S-135) , 

E  26  E;  Search  Operator  reports  new  contact  at  130°, 

T  50  D:  Supervisor  thinks  it  may  be  S-132  again;  hold  off  on  assigning 

new  tracker. 

E  27  E:  S-135  still  drawing  aft,  bearing  345°. 

T  53 
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E  30 
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E:  Search  Operator  reports  new  trace  at  157/203°  relatiye. 

D:  Supervisor  thinks  it  may  be  S-133  again;  hold  off  on  assigning 
tracker . 

P:  Contact  is  in  taffies  of  hull  arrays,  you  can’t  hear  it  with 
present  audio  selection, 

SI:  DEMON  from  contact  at  130°  looks  like  S-132- 


SI:  LOFAR  of  S-135  beginning  to  show  slight  down-doppler . 
(May  be  past  CPA) 

D:  Supervisor  is  changing  DL  sensor  to  towed  array. 


END  OF  PROBLEM 
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ERROR  AND  SYSTEM  QUESTION  CARDS  DOCUMENTING  PROBLEMS  DESCRIBED  IN  THE  TEXT 

'  The  cards  describing  operator  errors  or  questions  of  system  operation 
raised  during  the  run  throughs  of  the  scenarios  are  presented  in  this 
appendix ,  These  were  based  on  notes  made  during  the  running  of  the  scenarios 
and  tend  to  be  cryptic,  Seyeral  describe  multiple  mistakes,  only  one  of 
which  is  relevant  to  the  associated  problem  description. 

The  cards  are  organized  by  problem  number.  Each  card  is  identified  by 
a  running  head  of  the  form:  61:DLS,  2S/10,  D.  This  gives  the  card  number 
(61) ,  the  display  or  displays  where  the  problem  arose  (DLS) ,  the  scenario 
and  event  number  (2S/10) ,  and  the  subject  having  the  problem  or  raising  the 
question  (D) .  The  text  of  the  card  follows  immediately. 

Some  of  the  cards  also  have  notes  made  after  the  card  was  created, 
answering  the  question  posed  or  further  defining  the  problem.  These  notes 
are  placed  between  double  slashes  (//)  to  differentiate  them  from  the 
original  problem  description. 

Abbreviations  are  used  extensively.  For  the  most  part,  the  referent 
will  be  obvious  to  anyone  who  has  read  the  text  of  this  report.  Scenarios 
designated  "NF. ..”  are  the  TRACOR  "No  Fault"  scenarios  used  in  training. 

TA  stands  for  (sonar)  Threat  Alert,  and  AB  and  GM  are  the  authors. 
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Problem  1 


79: BB, l.g/10 ,  p.  Tried  to  initialize  tracker  on  new  contact  while  hooked 
to  Sr>142,  IDEA.:  Machine  should  giye  error  message  if  attempt  to  add 
a  tracker  to  a  file  at  a  bearing  radically  different  from  other  tracks 
in  file. 

//  SOP  -  unhook  ASAP  // 

80;BB,2S/2,  D,  When  S-132  detected,  pushed  ''initialize  tracker  at 
bearing”  when  hooked  to  S-131.  Some  kind  of  system  test  that  warned  of 
attempts  to  assign  additional  tracker  to  a  contact  at  different  bearing 
would  help  prevent  this ,  which  is  probably  the  most  common  error  with 
new  operators. 

100:CS,1CL/15,D.  Erroneously  assigned  tracker  to  previously  hooked 
contact  (vice  threat),  corrected  mistake  by  dropping  and  unhooking, 
then  pushed  "new  line  at  XXX",  creating  a  new  file  (threat  already  on 
file)  and  another  error.  Finally  did  it  right  (hooked  threat 1 s  file)  and 
had  to  go  to  CSD  to  delete  erroneously  created  file. 

105:CS,1CL/15,D.  After  TA,  initialized  tracker  while  hooked  to  previous 
non-threat  contact.  Some  test  for  tracker  approximation  to  others  in 
file  a  must. 

108:CS/CA,lCL/26,D.  Problem  -  begin  prosecuting  threat  while  hooked  to 
previous  contact.  Had  to  be  reminded  to  drop  hook. 

//  Implies  train  to  complete  processing  // 

222 :DL, 2S/19 ,  F.  Initialized  tracker  when  new  lines  appeared.  Two 
errors:  (1)  had  not  succeeded  in  unhooking  from  another  contact,  hence 

initialized  into  wrong  file,  and  (2)  failed  to  enter  lines. 

225:BB,2S/22,F .  New  BB  trace  -  initialized  tracker  ...  then  realized 
still  hooked  from  last  TA.  Again  hung  up  -  "complete  resource 
processing"  releasing  tracker  in  order  to  release  hook.  Used  4  pushes 
to  release  hook,  minimum  possible  here  2. 

265:CS,1CL/4,E.  Apparently  (only)  released  tracker  when  goal  was  to 
release  hook.  Then  initiated  tracker  to  old  (hooked)  contact  file  when 
new  line  (new  contact)  was  appropriate. 

Problem  2 

82 : BB,2S/6 ,E.  When  DL  S-131  appeared  on  BB,  called  new  trace  -  then 
dropped  trace,  hooked  S-131  and  assigned  tracker  to  that  file. 

//  Should  have  dropped  new  file?  // 

93:BB,2S/3,C.  Initializes  new  "trace  at  bearing"  for  BB  trace  on  DL 
contact  thereby  creating  new  file  (?  check  out  tests  and  error  messages 
for  new  trace  and  hook  VABs  re  more  than  one  file  on  same  bearing) . 
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Problem  2  (cont'd) 


284 : BB, 2S/3 ,G«  BB  gain  of  DL  contact.  Pushes  "new  trace;  maintain  file" 
vice  hooking.  Wants  to  correct  his  mistake  by  dropping  file  via  CSD 
but  Search  VABs  for  CSD  won't  let  him  do  it.  This  is  a  very  common 
error,  Also  tried  to  gain  access  to  a  drop  file  function  by  hooking  at 
bearing,  but  there  is  no  drop  file  once  it's  been  created, 

334:BB,2S/6,H,  Again  does  new  trace,  etc,,  when  should  have  hooked 
Sierra.  Old  contact  can  now  be  tracked. 

Problem  3a 

81  BB, 2S/2 ,D .  Subject  wants  to  use  "new  trace  at  bearing"  VAB  as  first 
step  in  assigning  second  tracker  for  triangulation. 

206:BB,2S/4,P.  In  order  to  add  second  tracker  to  triangulate,  pushes 
"new  trace  at  bearing"  on  towed  array  instead  of  hooking  and  adding 
tracker  and  resolving  ambiguity. 

210 : BB, 2S/6 ,F .  Created  new  file  (new  trace,  etc.)  on  CYL  when  should 
have  hooked  existing  file  on  TOW. 

283 : BB ,2S/2 ,G.  New  Contact:  "new  trace,  ATF",  then  "new  trace"  again 
(on  same  array  -  cylinder  vice  towed),  MTB  &  Hook,  ATF,  then  resolve 
bearing.  Possible  problem  with  multiple  files  at  same  bearing. 

315 : BB , 2S/2 ,H.  Trying  to  assign  a  second  tracker.  Created  a  second 
file  instead. 

319 : BB, 2S/4 ,H.  As  card  5,  event  2  -  Trying  to  put  on  tow  as  well  as  Cyl 
to  triangulate.  Assigned  a  second  file  instead. 

Problem  3b 

68 : BB, 2S/5 ,C .  Trace  stops  abruptly.  Does  "new  trace  at  bearing,"  MTB 
assign  and  hook"  instead  of  simple  "hook  at  bearing"  in  an  effort  to 
release  the  tracker . 

134:CS,2CL/25,E.  After  TA,  wants  to  assign  tracker  to  TA  line,  but  have 
it  in  old  contact's  file.  Pushed  new  line  at  freq.  and  bearing  (thereby 
creating  a  new  file  at  the  same  bearing) .  £ Should  there  be  some  way  of 
warning  of  this?}  Then  had  to  go  back  and  hook  (but  now  2  files  at 
bearing!)  and  assign  tracker  as  per  original  intention. 

286:DL,2S/9,G.  DL  decreasing  and  unlocking;  to  MTB,  pushes  "new  line 
at  XXX,  MTB  &  Hook". 

//  Makes  a  second  file.  // 

Problem  4 

47 :DL, 2 S/21, E.  Hooks  threat  .  (creates  new  file?),  starts  tracker.  Then 
gets  on  towed  array,  starts  second  tracker,  then  dropped  first  tracker. 
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Problem  4  (cont'd) 


//  Test  in  CS  flow  charts  -  TBD?  // 

52:DL,2S/21,A..  New  threat  line  from  old  contact  (to  which  hooked  at 
time  of  TA) ,  Pushes  hook  threat,  thereby  creating  a  new  file  at  same 
bearing.  Does  the  system  have  any  way  to  sort  this  out,  or  must  the 
supervisor?  Then  dropped  (automatically  assigned  tracker  on  conformal) 
and  added  on  towed  -  still  in  the  newly  created  extra  file. 

53:DL,2S/10,A,  Hooks  threat  (creates  new  file?):  threat  line  already 
in  file.  Then  released  that  tracker  and  assigned  a  new  one  on  TA.  Do 
we  now  have  2  files  on  same  contact?  Should  we  have  dropped  hook  and 
then  hooked  S-135? 

//  Should  have  entered  to  file  number  // 

55:DL,lA/8 ,A.  Second  TA  while  hooked  to  contact  (new  line,  same  contact) 
Pushed  "hook  threat"  thereby  creating  a  new  file  at  the  same  bearing. 
There  ought  to  be  some  kind  of  system  test  for  this  (overlapping  file) 
thing. 

105:CS/CA,1CL/15,A.  TA  from  S-144 .  Pushes  hook  threat  (now  3_  files 
at  bearing)  and  starts  tracker.  Wants  tracker  on  towed,  so  goes  back 
and  drops  first  tracker  and  re-initialises ,  still  in  third  file.  Need 
some  system  test  for  existing  files  on  threat  bearing  or  more  careful 
operation . 

//  Need  "hook  old  threat"  and  "hook  new  threat"  VABs  // 

107 :CS/CA,1CL/10,A.  Hooked  to  S-144  (via  class  channel  tracker  )  when 
TA  from  new  line  on  S-144.  Subject  acknowledges  threat  and  hooks  threat 
(new  file,  same  bearing,  different  frequency),  enters  new  line  via  C-S, 
then  proceeds  with  signature  assembly  as  planned,  still  hooked  on  threat. 
Do  we  now  have  2  files  at  same  bearing,  first  with  1  tracker  and  Sierra 
Number  assigned,  second  with  1  tracker? 

213:  DL,2S/10,F.  Treated  as  a  false  alarm  the  hard  way:  ATF  ASGN 
followed  by  RELEASE  TRKR. 

297 :DL,1S/6,E.  TA  from  contact  in  file,  pushed  "hook  threat"  causing 
additional  file  at  same  bearing.  Should  have  entered  to  file  number. 

304 :CS, 1CL/9,E,  New  line  from  contact  on  file,  "hooks  threat"  vice 
"enter  to  file  #". 

306:CS ,1CL/14 ,E .  Subject  "hooks  threat"  vice  "enter  to  file"  or  "false 
alarm".  Question:  Does  "hook  threat"  response  have  "return  to  previous 
options"  escape  route?  Check  FOD:  It  ought  to:  this  is  a  very  common 
mistake. 

308 ;CS/CA, 1CL/25 ,E .  TA,  "hook  threat"  vice  "enter  to  file"  or  "false 
alarm".  Then  goes  to  enter  new  speed  to  CMA  before  assigning  tracker  or 
otherwise  completing  TA  sequence.  Then  wants  to  drop  hook,  gets  cue 
"complete  resource  processing",  "maintain  file"  and  drops. 


Problem  5 


88;BB,lS/2 ,D,  Subject  wants  to  change  array  to  conformal  (yiqe  cylinder) 
but  confused  because  display  selection  tiers  not  available  when  hooked. 
Finally  puts  tracker  on  conformal  without  displaying  it  (uses  SNR  meter 
to  check  placement) . 

95;BB,2S/3,C,  Having  to  drop  hook  to  change  BB  fields  displayed  may 
be  an  inconvenience, 

//  Standardize  drop  hook  // 

234:BB,2S/6,B.  Hooked  to  contact  when  21/15,  wants  to  look  at  7,  can't 
reach  "display  source  select"  when  hooked,  some  problem  remembering  to  . 
unhook  to  give  access. 

Problem  6 

123:CA,2CL/4,C.  Responds  to  report  of  new  contact  with  "hook  CICh 
tracker"  before  he  has  assigned  a  class  channel.  His  comment  -  should 
be  better  way  of  hooking  -  so  it  doesn't  alter  the  displayed  choices  - 
in  particular  the  option  to  assign  a  class  channel  to  the  hooked  contact. 
Subject  at  this  time  still  not  clear  on  how  or  why  to  hook. 

124:CS,2CL/2 ,D.  Subjects  hooks  new  contact  at  tracker  bearing  before 
has  assigned  class  channel.  Has  to  go  back  and  drop  hook  before  he  can 
proceed. 

//  Error  or  AB  interpretation  of  way  system  must  be  used.  Hook  limits 
access.  // 

125 :CS,2CL/10,D.  Operator  hooks  new  contact  to  begin  prosecution  before 
has  assigned  Class  Channel.  A  recurring  error. 

126:  CS,2CL/1,D.  Subject  wants  to  hook  new  contact,  then  assign  class 
channels.  Doesn't  see  logic  in  having  class  channel  assignment  tiers 
inaccessible  when  hooked. 

//  Not  on  Contact  Status  // 

128:CS,2CL/1,C.  Responds  to  report  of  new  contact  by  hooking  at  XXX  & 
bearing.  Said  it  seemed  reasonable  (it  makes  class  channel  assignment 
tiers  unreachable)  and  then  had  to  drop  hook  to  continue. 

//  Move  2. 6. -1,2  to  right}  conflict  with 
2.6-4  to  left?}  other  tiers  // 

268:CS,1CL/9,F.  System  characteristic  -  If  hooked  and  want  to  assign  a 
class  channel  using  Class  Summary  Display  -  "Must  unhook  to  assign  channel." 
Quote  from  data  sheet. 

289:CS,2CL/1 ,G.  MTBing  weak  DL  line,  wants  to  assign  CL-CH  (to  fixed 
beam  -  would  CL-CH  move  with  cursor  doing  MTB?)  and  tries  to  drop  hook 
before  releasing  tracker.  Error  cue  "complete  resource  processing"  OK 
here. 

//  Go  to  Contact  Status  if  want  to  hold  hook.  // 
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Problem  6  (cont'd) 


290:CS,2CL/2,G,  Told  of  new  contact,  tries  "hook  at  tracker  bearing" 
as  first  step  in  assigning  Class  Channel,  Why  Class  Channel  not 
available  when  hooked? 

291:CS,2CL/6fG,  Told  of  new  contact.  First  step  is  "hook  at  tracker 
bearing"  assigning  Class  Channel,  Second  time  he’s  done  this. 

Problem  7a 

26:CS,NFSUP/J,D,  LAMPAZ  assignment  for  CS  not  accessible  when  hooked, 
yet  more  likely  to  be  desirable  for  contact  of  interest  (which  is  more 
likely  to  be  hooked)  than  for  a  routine  one. 

132 :CS/CA, 1CL/10, A.  Trying  to  get  new  line  onto  LAMPAZ  while  still 
hooked  and  CS  hooked  tier  won't  let  him.  Calls  up  signature  (which 
has  1  line  in  file)  and  transfer  signature  to  LAMPAZ  from  CA.  Awfully 
round-about. 

//  Build  LAMPAZ  and  Signature  only  after  have  several  lines.  // 

133 :CS ,NFSUP/J ,E.  Wants  to  enter  line  to  LAMPAZ  when  hooked  on  one 
contact  and  has  to  unhook  to  reach  LAMPAZ  tier.  Note  says  notion  of 
unhooking  to  reach  certain  controls  still  a  bit  shakey. 

//  See  132  //  . 

Problem  7b 

113 :CS/CA, 1CL/4 , A.  CL  has  4  lines  on  S-143.  Moved  first  2  to  LAMPAZ 
via  2. 7. 6. 2-0  about  10  minutes  ago.  Elects  to  do  it  again  now  that 
there  are  more  lines.  Does  this  operation  leave  the  previous  lines 
unaffected  or  would  the  machine  start  over  fresh?  Also,  what  will 
happen  if  he  tries  this  with  partial  signatures  from  more  than  one 
contact.  Will  the  machine  drop  lines  from  the  first  (partial) 
signature? 

//  Yes  it  will .  // 

.  130 :CA , 2CL/24 , D .  New  line  appearing  on  contact  being  tracked.  Enters 
line  to  file  via  top  tier  (CS)  (hooked)  then  to  working  signature  with 
same  (but  having  different  action)  VAB  in  Signature  Assembly  tier. 
Awkward . 

131 :CS/CA, 1CL/12 ,A.  Subject  transfers  signature  to  LAMPAZ  almost 
every  time  a  new  line  is  added.  Would  this  interfere  (i.eM  restart 
data  accumulation)  with  lines  that  were  already  on  LAMPAZ? 

//  This  VAB  moves  temporary  vector  to  LAMPAZ  -  can  only  have  one  contact 
on  LAMPAZ.  // 

150.-CS/CA,  1CL/13  ,D,  Has  assembled  signatures  for  2  contacts  and  trans¬ 
ferred  both  to  LAMPAZ.  Question;  Does  the  system  give  any  warning  if 
the  transfer  of  a  signature  is  going  to  cause  the  bumping  of  already 
established  LAMPAZ  lines? 

//  NO  // 
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Problem  8 


17 ; CSD , NFSUP/E6 , D ,  In  3, 4.0,1  VABs  to  release  and  assign  correlation 
and  class  channels  result  in  automatic  return  to  3,4  or  3,4,1,  This  is 
a  nuisance  if  both  correlation  and  class  channels,  or  more  than  one  of 
each,  is  assigned, 

//  Room  for  return?  YES  // 

Problem  9 

144:CA,NFCL/Q,E.  Comment:  Harmonic  comb  on/off  VAB  unnecessary  on  this 
tier.  If  wanted  harmonic  comb  off,  wouldn't  have  called  this  tier  in 
the  first  place. 

148 :CA, 1CL/21 ,D .  In  using  harmonic  comb,  subject  has  turned  "harmonic 
comb  on/off"  to  "on. "  Check  FOD  to  see  if  it  always  comes  up  in  the 
"on"  position.  If  it  doesn't,  it  should. 

Problem  10 

147 :CA, 1CL/2 ,D .  In  assembling  signature,  pushed  "enter  lines  displayed" 
VAB  before  he  had  entered  any  lines  to  the  signature  field.  "ENTER"  in 
this  and  "enter  lines  at  XXX”  VAB  may  be  too  easy  to  confuse? 

152 :CA/CS,NFCL/E,C .  Entering  a  single  new  line  to  the  file  when  hooked 
and  in  a  signature  assembly  mode  is  awkward.  VAB  "Enter  Line"  puts 
line  on  signature  field,  not  in  file.  To  get  to  file,  must  then 
"enter  lines  displayed"  which  transfers  all  the  lines  to  the  file 
(including  possibly  shakey  ones).  Since  the  frequency  cursors  are 
slaved  on  a  console,  it  may  be  possible  to  get  around  this  problem  by 
entering  the  single  line  on  CS  if  that  display  is  available. 

154:CA/CS,2CL/16,C.  Additional  lines  on  gram:  hooks  at  tracker  bearing 
on  CS  vice  CLCH  or  CA.  Then  pushes  "enter  lines  displayed"  before 
"enter  line  at  XXX."  (Enter  line  at  XXX  confusing  because  enters  to 
signature  field  but  not  directly  to  file  as  on  other  displays.) 

182 : CA , 1CL/10 , H .  Did  "enter  lines  displayed"  vice  "enter  line  at  XXX." 

186:CA,lCL/2 ,H.  Activated  "enter  lines  displayed"  when  should  have 
touched  "enter  line  at  XXX." 

273:CA,lCL/16,F.  Entering  lines  to  signature,  pushes  "enter  lines 
displayed"  before  "enter  line  at  XXX"  which  is  backwards. 

294 :CA, 2CL/15 ,G.  Was  slow  to  "enter  lines  displayed"  after  several 
"enter  line  at  XXX."  Probably  needed  to  be  reminded,  but  notes  don't  say. 
//  May  not  want  to  do  ELD;  does  FOD  suggest  this  sequence?  Don't  believe 
so.  // 

305:CA/CS,1CL/? ,E.  Subject  "enter  line  at  XXX"  and  moves  to  LAMPAZ  but 
does  not  "enter  displayed  lines"  so  not  on  file. 

//  Wouldn't  necessarily  want  to  clear  and  fill  contact  file.  // 
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Problem  11 


167:CA,2CL/17,D,  From  hooked  top  tier  subject  uncertain  how  to  get  to 
"maneuver  detect"  VAB, 

170;CA:NFCL/R,D»  YAB  label  "update  CMA"  mildly  misleading,  "Access 
CMA"  would  be  better, 

171:CA,NFCL/R,A,  Has  trouble  getting  to  CMA  through  Loc/Range  History. 
Possible  some  memory  problem  as  in  #2;  possibly  VAB  labels  could  be 
more  helpful. 

172:CA,NFCL/R,C.  Subject  has  trouble  remembering  that  you  have  to 
reach  CMA  update  via  "localization/range  history".  Perhaps  changing  the 
name  of  this  set  of  tiers  would  make  it  a  bit  easier  to  learn. 

238:CA, 2CL/10,B.  Subject  has  trouble  remembering  access  to  ZIG  detect 
via  loc -range  history.  IDEA:  Possible  change  name  of  VAB  to  "contact 
motion  analysis." 

276:CA,1CL/19,F.  Detects  speed  change  on  DEMON,  tries  to  reach  CMA  via 
"sig  ass"  instead  of  "loc/range  hist."  Recovers  promptly. 

Problem  12 

230 :CS, CL/2 ,B.  Class  Channel  assignment  tiers  terminates  in  Class 
Channel  processing  option:  "full"  and  "extended."  "Full"  should  be 
"norm"  to  agree  with  same  options  in  CA. 

//  Neither  self-explanatory.  // 

Problem  13 

280 :CA , 1CL/25 ,F .  In  MPR,  pushed  "compute  range?  ranging  complete", 
then  went  back  to  loc/range  hist  ajtd  pushed  enter  range.  System  would 
have  required  that  he  mark  correlation  peaks  and  compute  range  again. 
"Compute  Range"  VAB  should  say  "compute  trial  range." 

Problem  14 

142:CA,  NFSUP/F4,D.  "Select  vernier  process"  much  like  "select  dem/vern 
displays."  " Assign  vernier  process"  would  be  better. 

Problem  15 

33 : BB/DLS/CS , 2CL/2 ,D ,  BB  operator  pushes  "new  trace  at  bearing"  and 
starts  a  tracker.  Does  he  know  the  tracker  number?  Then  the  CL  operator 
starts  to  assign  a  CL-CH  via  unhooked  CS.  How  does  he  know  the  tracker 
number  to  assign  the  CL-CH  to?  Does  someone  have  to  be  looking  at  the 
contact  status  display  to  recover  the  tracker  number?  An  alternative  to 
this  is  for  the  CS  operator  to  "hook  at  bearing",  read  the  tracker 
number  from  the  (hooked)  tracker  table,  unhook,  and  then  assign  a  CL-CH 
but  it  seems  very  cumbersome. 


V)  o 


Problem  16 


51;DL,NFS/G,P.  RE:  Process  of  entering  alarm  line  to  file;  "Row 
would  you  know  what  file  you  have  somebody  in,  .Maybe  Sierra  number 
would  be  easier  (as  an  indexing  system)," 

102 :CS, 2CL/12 ,D.  TA  from  line  with  tracker  assigned.  Wants  to  enter 
to  file.  How  does  the  operator  know  file  if  he:  (a)  isn't  hooked  to 
the  threat  contact,  or  (h)  didn't  start  the  file  himself? 

//  Not  an  error  <-  unless  judge  should  call  False  Alarm  // 

287:DL,2S/21,G.  TA  acknowledged  with  "enter  to  file  #".  TA  when  hooked 
to  contact  of  interest  likely,  also  system  knows  what  file  is  at 
bearing  of  TA.  "Enter  to  file  at  bearing"  VAB  might  be  quicker,  save 
operator  from  looking  up  file  number. 

//  May  be  >  1  contact  at  bearing  // 

Problem  17 

11:CSD/CA,2CL/24,D.  TA  with  CSD/CA  up,  pushed  TA,  got  error  cue 
"select  DL  search  display"  and  did  just  that  (vice  selecting  CS) .  Error 
cue  misleading. 

45 :DL/CS , 2CL/24 ,E.  Configured  DS(U)/CA  when  TA.  Dropped  hook  on  one 
contact  then  (following  displayed  cue)  put  up  DLS  when  really  wanted  CS. 
Acknowledged  alarm,  then  put  DS(U)  back.  TA  again  and  this  time  put 
up  CS. 

104 :CS,NFCL/T,E.  Called  DL  when  wanted  CS  in  response  to  cue  "select 
DLS." 

Problem  18a 

37:CM,1CL/2,D,  Gets  several  "invalid  command"s  when  tries  to  enter 
other  data  before  has  pushed  "enter"  FAB  on  first  datum.  This  wouldn't 
happen  with  real  system  due  to  blanking  of  VABs  (which  we  suppressed) . 
Perhaps  that  error  supports  wisdom  of  blanking  VABs  when  entry  pending. 
(Could  you  make  a  case  for  blanking  all  but  last  selected  VAB,  to 
remind  him  which  he  was  doing  if  he  was  interrupted?) 

18 3 : CA , 1CL/4 , H .  Incorrect  response  to  "enter"  re  contact  speed. 

Error  message  "invalid  command"  not  informative. 

Problem  18b 

35 :CM, 2CL/7 ,D .  Tried  to  drop  hook  while  "enter  number  at  index"  pending 
on  CM.  Error  message  said  "selection  invalid".  Not  very  helpful  -  not 
as  good  as  "enter  number  on  other  display",  which  we  have  seen  in  other 
contexts. 

38 :CM, 2CL/13 ,C ,  Tries  to  drop  hook  while  enter  pending.  Gets  "selection 
invalid"  as  error  message.  Not  helpful  at  all. 
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Problem  183d  (cont'd) 


274;CMrlCX,/16,F,  Tries  to  drop  hook  when  entry  pending  from  "line  # 
from  tag”.  Error  one  is  "selection  invalid”  »-  not  very  helpful. 

296:BB, 1S/4,E,  Tries  to  drop  hook  in  middle  of  release  tracker  number 
(before  number  is  entered).  Error  cue  is  "selection  invalid,"  instead 
of  the  more  informative  "complete  resource  procession,”  Check  sequence. 
£[  persisted  in  pushing  drop  hook,  perhaps  because  our  display  did  not 
blank  and  the  enter  FAB  not  as  conspicuous  as  would  be  in  real  system. 

In  desperation,  pushed  release  tracker  number  on  DLS;  error  cue 
changed  to  "enter  #  on  other  display",  much  more  informative.  Finally 
entered  number  and  was  allowed  to  drop  hook,  even  though  he  had  an 
entry  pending  on  DLS,  too  (or  did  it  ignore  this  when  it  gave  the 
error  cue?) 

Problem  18c 

34:CM/CA,2CL/25,D.  Enters  info  to  CM  when  TA,  pushes  TA  and  gets 
.  "selection  invalid"  error  cue  (an  entry  was  pending  on  CM  when  TA 
sounded).  Again,  error  cue  displayed  not  very  helpful. 

Problem  19 

277 :CA, 1CL/19 ,F .  Extra  VAB  "enter  computed  range"  at  end  of  CMA 
entry  -  ?  (what  would  ISPE  do  in  this  case?) 

Problem  20 

71:BB,2S/24,C.  To  resolve  crossed  trackers,  drops  one  from  weaker 
contact  and  starts  a  new  one  at  the  correct  bearing.  Would  this  mean 
CMA  had  to  start  from  scratch? 

228:BB,2S/24,F.  Trackers  merged,  operator  is  supposed  to  separate. 
Apparently  decided,  after  listening,  that  one  audited  first  was  OK. 

Then  instead  of  listening  to  second  and  MTBing  to  correct  track, 
operator  released  tracker,  put  new  tracker  in  ATF  on  TOW. 

Problem  21 

99:BB,2S/18,E.  Sees  transient  on  STA  at  position  where  BB  contact 
stopped  -  hooked  to  DL  contact  in  MTB  -  elects  to  do  nothing. 

//  Judgment  call  -  should  have  SOP  for  this  -  others  reported  to  Supv  - 
probably  appropriate  if  this  (Search)  console  manned  by  rates  other 
than  sonar.  // 

333:BB,2S/5,H,  Subject:  "Need  OP  guidelines  on  maintaining  log  for 
intermittent  noises." 

Problem  22a 

169 :CA,NFSUP/W,D.  Two  comments  on  business  of  inhibiting  tracker  to  CMA 
1.  Is  there  a  practical  difference  between  inhibiting  and  dropping 
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Problem  22a  (cont'd) 

169;CA,NFSUP/W,D  (copt'd) 
a  tracker? 

//  YES  // 

2,  Whole  business  of  controlling  CMA  might  best  be  done  on  GeoSit  or 
even  a  separate,  dedicated  display,  (This  last  comment  appears  in 
final  debrief,  too,) 

Problem  22b 

160:CA, 2CL/8 ,D ,  After  MPR,  chose  to  "update  CMA" ,  "enter  range"  vice 
"enter  computed  range".  Not  really  clear  on  the  difference  in  effect. 
Special  guidance  on  this  part  would  be  helpful. 

163 :CA ,2CL/4 ,A.  With  new  contact  in  bow  quadrant,  does  MPR  and  "enter 
computed  range"  and  then  enters  range  again  via  update  CMA.  Is  this 
necessary? 

165:CA,2CL/8,C.  New  contact  almost  dead  ahead.  Does  MPR,  then  chooses 
to  enter  range  via  "update  CMA,"  "Enter  range"  vice  "enter  computed 
range"  (on  reader's  prompting) .  Is  this  a  better  way  to  do  it? 

Problem  22c 

21:CA,1CL/0,C.  When  contact  maneuver  reflected  in  turn  count  that  allows 
calculation  of  his  speed,  is  it  better  for  CMA  operator  to  enter 
"maneuver  detect",  "speed  change",  and  the  new  speed,  or  just  to  enter 
the  new  speed  without  signalling  maneuver  detect? 

//  Must  start  solution  over.// 

168 : CA , 1CL/19 , A .  Detects  maneuver  and  determines  speed  for  DEMON 
analysis.  Enters  contact  maneuver  and  new  speed.  Is  this  the  best  way 
to  do  it  or  would  entering  the  new  speed  alone  be  enough?  If  speed 
alone  not  best,  a  machine  cue  to  at  least  consider  "maneuver  detect" 
might  be  useful. 

Problem  23 

23:CA/CA,2CL/24,C.  Subjects  thinks  TA  on  every  console  a  serious 
distraction,  especially  for  CL  operator. 

//  Agree  // 

109:CA/CA , 2CL,D.  Subject,  says  responding  to  TAs  while  tracking  a  contact 
and  working  between  CA  and  CM  too  much  of  a  burden  for  class  operator. 
Supervisor  should  do  it. 

//  Check  with  Rick  -  supervisor  enter  classification  data?  Problem  in 
allocation  of  function.  // 

Problem  24 

1151 : CA/CS , NFSUP/L , D ,  NUSC  program  will  not  accept  VAB  command  to 
transfer  signature  line  to  LAMPAZ  unless  CS  is  being  displayed.  Since 
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Problem  24  (cont’d) 

CA/Cty  is  frequently  up  a  large  part  of  the  time  during  classification, 
this  restriction  may  slow  down  a  busy  operator.  Is  it  a  safety  feature? 
//  No  problem,  but  CM  should  be  SUPy  job,  // 
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APPENDIX  C 


SUBJECT  DEBRIEFS 


SUBJECT  DEBRIEFS 


At  the  conclusion  of  the  week  of  training  and  testing,  each  subject  was 
interviewed  to  obtain  his  evaluation  of  various  aspects  of  the  system  and 
any  suggestions  he  might  have  for  improving  it.  The  first  four  of  these 
interviews  were  unstructured  and  the  last  four  followed  a  protocol 
(presented  on  the  next  page) .  Notes  taken  during  these  debriefings  are 
reproduced  on  the  following  pages. 
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ISPE  Pe brief  Protocol 


1.  Were  there  ever  instances  when  you  wanted  to  do  something  but  had  a  hard 
time  figuring  out  how  to  get  the  system  to  do  it? 

2.  Do  you  have  any  feeling  that  the  arrangement  of  the  control  tiers 
imposes  an  order  on  the  way  you  do  things  with  this  system?  (if  yes)  Do  you 
find  the  imposed  order  helpful?  Annoying?  Restricting?  Do  you  think  the 
imposed  structure  makes  this  system  easier  (harder)  to  use?  Do  you  think 
the  imposed  structure  would  make  this  system  easier  (harder)  to  learn  to 
use?  For  a  new  sonarman? 

3.  Did  you  find  any  of  the  VAB  labels  unintelligible?  What  (better)  labels 
would  you  use?  Did  you  find  any  of  the  VAB  labels  misleading  in  that  the 
function  they  control  wisn't  what  you  thought  it  would  Joe? 

4.  Were  any  functions  awkwardly  implemented?  How  would  you  streamline  them? 

5.  What  equipment  do  you  use  now  to  perform  this  function? 

a.  Do  you  think  it  or  ISPE  is  easier  for  you  to  use? 

b.  Is  there  any  instance  where  your  current  equipment  is  easier  to  use? 
What  makes  it  easier  to  use? 

6.  Are  there  places  Where  controls  should  be  grouped  together  but  are  not? 
Did  having  to  go  to  a  different  tier  to  operate  one  control  ever  put  others 
that  you  would  want  to  use  concurrently  out  of  reach? 

7.  Could  you  find  every  piece  of  information  you  wanted  on  the  display? 

a.  Were  the  display  readouts  grouped  in  a  way  that  would  make  them 
easy  to  use? 

b.  Was  there  anything  you  thought  was  a  waste  of  display  space? 

8.  Did  the  arrangement  of  the  displayed  readouts  or  data  fields  ever  suggest 
an  analysis  you  might  not  have  thought  of  otherwise? 

9.  Would  you  have  laid  out  the  displays  any  differently  if  you  had  been 
the  designer? 


Subject  A,  STS2 (SS) 


1.  Problems  implementing  desired  actions,  None,  once  familiar  with  the 
capabilities  of  each  display  I  but  this  was  a  small  problem  -  learning 
what  each  display  can  do  for  you  takes  a  while  (especially  in  the  case 
of  class«-analysisf.  which  does  so  many  things)  and  S  was  often  uncertain 
which  display  to  select]* 

2.  Imposition  of  order  by  the  control  structure.  S  was  aware  of  this,  but 
the  order  was  '"just  the  way  the  machine  was,"  not  difficult  to  adjust 
to  and  "seemed  logical." 

2a.  Was  this  order  helpful?  The  control  structure  (tiers  of  VABs).  was  much 
easier  to  use  than  an  (equally  versatile)  array  of  dedicated  switches 
would  be  -  "helpful,  as  a  matter  of  fact." 

2b.  Did  it  make  the  system  easier  to  use?  [The  restricted  set  of  choices! 
"helps  to  make  the  choice  of  the  next  action." 

2c.  Does  the  structure  make  the  system  easier  to  learn?  "I  had  3  weeks  of 

BQR-21  operator  training,  and  then  was  not  comfortable  with  it,"  but  was  . 
fairly  comfortable  with  ISPE  after  4  days.  "Yeak,  its  going  to  be  good  - 
If  you  give  3  weeks  training  on  it  I’d  be  comfortable  as  a  supervisor." 

"The  control  structure  [should  be]  much  easier  [than  current  systems] 
for  a  new  operator  to  learn  ...  he  will  learn  faster  because  it  is  a 
step-by-step  lay  out."  [However]  for  initial  training  on  ISPE  "better 
use  people  who  have  been  to  sea." 

3.  Were  VAB  labels  unintelligible?  No,  though  they  were  too  close  together 
on  this  [NSMRL  simulation]  screen.  Making  sense  of  the  labels  is  easier 
if  you  already  know  sonar.  Some  of  the  displays’ names  were  misleading, 
e.g.,  hard,  to  connect  "Class-Analysis"  with  MPR  and  CMA  management 
functions  and  "Class-Summary"  is  a  better  name  for  the  [hooked]  Class 
Menu  or  Contact  Status  Display  than  the  present  "Class  Summary." 

4.  Were  any  functions  awkwardly  implemented?  Ratio  compute  has  an  unnecessary 
extra  step  in  "compute  ratio"  after  "mark  #2." 

5.  What  current  equipment  performs  these  functions?  -  Skipped  this  question. 

6 .  Are  any  of  the  controls  improperly  grouped  together?  No . 

7.  Was  the  display  layout  adequate?  In  this  simulation  [he]  wasn’t  paying 
much  attention  to  the  projected  displays  [because  they  contained  no  data]; 
interested  in  hooked  or  unhooked  status  only, 

8.  Did  the  arrangement  of  the  display  ever  suggest  an  analysis?  In  general, 

.  no. 

9-  Would  you  lay  out  the  display  differently?  [Possibly];  he  disliked 
having  ranging  and  CMA  functions  on  "Class-Analysis,"  "Classification 
and  ranging  on  the  same  thing  is  a  mistake  . , .  Ranging  should  be  done 
by  the  supervisor . "  [The  ranging  capability  is  a  nicety,  not  an 
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essential  part  of  classification. 3  "Why  does  the  class  operator  care 
hov  far  away  he  [the  contact!  is  -  he  doesn’t.  Why  put  all  these 
functions  on  the  class  display  and  then  haye  something  [as  simple  - 
and  error  prone!  as  detection  prediction  on  a  display  by  itself  - 
"It  doesn’t  seem  logical  to  me." 

"Detection  prediction  «  who  cares  -  it's  neyer  going  to  be  right  anyway 
just  going  to  giye  the  QOD  something  to  worry  about  that  he  doesn't 
need  to."  ["If  CMA  or  other  ranging  doesn’t  agree  with  the  range  of 
the  day,  the  00D  will  hassle  sonar"  -  OOD's  don't  appreciate  how 
approximate  the  range  of  the  day  is:  they  tend  to  think  sonar  is 
malfunctioning  or  goofing -off  if  every  contact  is  not  detected  at  the 
predicted  range.! 


Subject  B,  STS3 (SS)  (before  protocol) 

1.  One  Suggestion:  Harmonic  comb  useful  in  tracking  operations,  possibly 
should  be  available  in  "loc/range  history"  tiers. 

2.  Hooked  concept  difficult,  especially  idea  that  different  controls  are 
available  when  hooked  than  when  not  hooked. 

3.  Thinks  Contact  Status  log  a  great  help  with  the  large  number  of  trackers 
and  correlation  channels  available. 

4.  Notes  no. explicit  use  of  doppler  information  by  operator.  Says  programs 
for  the  Tektronix  4051  uses  doppler  in  CMA  -  does  ISPE?  (Yes,  but  not 
in  a  way  that  lets  the  operator  know  how  the  doppler  is  affecting  the 
CMA.) 

5.  Subject  thinks  well  of  the  system:  "It  seems  to  have  all  the  features 
you  could  want . " 


Subject  C,  STS3 (SS) 

1.  Problems  implementing  desired  actions.  The  hooked/unhooked  status  was 
sort  of  a  problem  [especially  the  idea  that  you  had  to  be  unhooked  to 
do  certain  things,  e.g.,  assign  class  channels!  but  that  was  about  the 
only  thing  -  "once  you  know  it,  it's  all  within  reach." 

2.  Imposition  of  order  by  the  control  structure.  The  subject  was  aware  of 
the  structure  inherent  in  the  arrangement  of  the  control  tiers ,  and 
preferred  it  to  the  lesser  structure  of  an  array  of  dedicated  switches. 

2a.  Was  this  order  helpful?  "...  yeah.  It  more  or  less  leads  you  right 
where  you  want  to  go  ...  [it's!  giving  you  hints." 

2b.  Did  it  make  the  system  easier  to  use?  Yes, 
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2c,  Does  the  structure  make  the  system  easier  to  learn?  [Possibly  not: ] 

"...  Itfs  harder  to  learn  . because  it's  different  from  any  other  sonar 
I  eyer  used  the  old  systems  [are]  more  straight  forward  -  [you're] 
listening  to  one  contact  and  one  contact  only*  You  don't  put  a  contact 
into  a  file  and  leave  it  and  come  back  «->  you  have  it.  right  in  front  of 
you." 

3.  Were  VAB  labels  unintelligible?  Generally,  no  Ithough  this  S  got  mixed 
up  about  classification  and  correlation  channels,  possibly  because  of 
the  similarity  of  the  VAB  abbreviations], 

3a.  Were  VAB  labels  ever  misleading?  Yes.  The  "new  line"  VABs  which 

indicated  new  contacts  ]_S  wanted  to  use  these  to  indicate  a  new  line 
from  an  old  contact] . 

4.  Were  any  functions  awkwardly  implemented?  The  subject  felt  that  some 
were,  but  couldn't  give  any  specific  examples.  As  the  class-loc 
operator,  he  didn't  like  having  to  go  through  "display  select"  every 
time  he  wanted  to  enter  classification  information  via  Class-Menu. 

He  suggested  a  VAB  on  Class -Analysis  to  put  up  Class-Menu  and  a  VAB  or 
a  FAB  to  replace  it  with  whatever  was  being  shown  before,  as  an  alter¬ 
native  to  the  present  procedure  of  reconfiguring  the  console  via 
"display  select." 

5.  What  current  equipment  performs  these  functions?  Skipped  this  question. 

6.  Are  any  of  the  controls  improperly  grouped  together?  No.  The  system  is 
generally  well  thought  out  and  the  FABs  cover  a  lot  of  major  contingencies 
[but  see  4  above]. 

7.  Was  the  display  layout  adequate?  "It's  hard  to  talk  about  the  displays 
because  we  didn’t  actually  refer  to  them  that  much:"  His  general 
impression  was  that  display  layout  was  reasonable. 

8.  Did  the  arrangement  of  the  displays  ever  suggest  an  analysis?  No. 

"Some  buttons  LvABs]  are  kind  of  misleading  that  way  -  some cf  the 
things  accessed  [e.g.,  CMA  entry  via  "localization/range  history"]  were 
not  explicitly  mentioned."  [Perhaps  a  different  VAB  label,  e.g., 
"ranging/CMA"  would  be  a  better  cue  here.] 

9.  Would  you  lay  out  the  displays  differently?  "I've  never  seen  [the 
actual  control  panelsj  so  I  wouldn ' t  know  . . .  Like  I  said  before  [4 
above]  a  FAB  for  returning  to  the  previous  display  [which  the  present 
display  replaced]  -  I  definitely  would  have  included  that." 


Subject  D,  STS2 (SS) 

1.  Problems  implementing  desired  actions.  "Basically,  no,  though  there 
were  occasional  memory  lapses  -  couldn't  remember  which  display  did 
what  ...  otherwise  OK." 


2.  Imposition,  of  Order  by  the  control  Structure,  "Everything  falls  in  place 
in  the  order  in  Which  you  would  do  it  anyway  -  I  was  satisfied  with 

the  order," 

2a.  Was  this  order  helpful?  "probably  helpful,  if  anything," 

2b.  Did  it  stake  the  system  easier  to  use?  "[it's]  easy  enough  to  learn  as 
long  as  you  can  get  the  associations  down,  between  tiers  -  you*re  going 
to  have  to  go  by  steps  and  that's  the  easiest  way  to  learn:  to  go  by 
steps."  "DO  new  roan  might  have  problems  -  just  the  sheer  complexity 
of  it  all.  He  will  need  a  pretty  good  handle  on  sonar  before  he'll  be 
able  to  grasp  -  what  it  will  do  for  him.  If  he  doesn't  Understand 
sonar,  he  won't  understand  this  machine  ...  If  he  understands  sonar, 
then  this  machine  will  be  no  problem."  [Subject  said  that  present 
sonar  "A"  school  was  of  poor  quality:  graduates  "won’t  cut  it  with 
ISPE  -  can't  cut  it  with  what  we  have  now  . .  ."] 

3 .  Were  VAB  labels  unintelligible?  No . 

4.  Were  any  functions  awkwardly  implemented?  "No,  everything  seemed  OK." 

5.  What  current  equipment  performs  these  functions?  Skipped  this  question. 

6.  Are  any  of  the  controls  improperly  grouped  together?  [Possibly] 

Ranging  and  CMA  functions  shouldn't  be  on  "Class-Analysis":  "Give  it  a 
separate  display.  For  example,  TMA,  GeoSit,  and  ranging  should  be  sort 
of  grouped  together.  The  search  operator  would  handle  this  -  it's 
quick  and  easy.  Definitely  gram  analysis  calls  for  its  own  man:  we 

do  it  this  way  and  it  [by  itself]  still  proves  hectic  for  him." 

7.  Was  the  display  layout  adequate?  "For  the  amount  of  information  on 
these  displays,  they're  arranged  pretty  good,-  I  like  the  way  part  of 
the  display  will  change  depending  on  which  VAB  you  hit."  There  is  no 
waste  of  space.  "I'm  glad  to  see  GeoSit  and  TTM  -  they're  good  ideas. 
Sonar  should  be  able  to  get  the  big  picture  . . .  this  is  becoming  a 
lost  art." 

8.  Did  the  arrangement  of  the  display  ever  suggest  an  analysis?  "Not 
really.  I  knew  where  I  was  going  most  of  the  time:  when  I  pushed  a 
button  I  was  ready  to  push  the  next  one  [in  a  multi-tier  sequence]." 

9.  Would  you  lay  out  the  display  differently?  "Other  than  a  separate 
ranging  display,  no,"  "Maybe  a  way  of  recalling  the  last  [previous] 

10  minutes  of  a  gram  ..."  [when  reminded  that  the  grams  were  11.8 
minutes,  he  though  that  it  was  probably  adequate.]  "I  like  the  idea 
that  you  can  record  a  display  -  it's  good  [though  it  will  be  one  more 
thing  to  include  in  ACINT  packages] . M 
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Subject  E,  STS2  (SS) 


1.  Problems  implementing  desired  actions,  "Not  after  I  got  to  know  it" 

[some  problems  initially  ^  mostly  remembering  what  display  would  allow 
a  desired  action]  -  "but  that's  true  of  anything  . " 

2.  Imposition,  of  order  by  the  control  structure.  The  subject  was  aware  of 
this. 

2a.  Was  this  order  helpful?  "...  generally  helpful  -  there's  an  order  in 
things  {_ operator  actions]  anyway," 

2b.  Did  it  make  the  system  easier?  [the  restricted  set  of  choices]  if 
anything,  the  order  was  beneficial  -  "for  operator  purposes,  it’s 
excellent  the  way  it's  set  up  to  work  [now]. 

2c.  Does  the  structure  make  the  system  easier  to  learn?  "[it  should  be] 

easy  for  a  new  operator  to  learn.  However,  if  they  intend  to  teach  all 
the  system  functions  ( Class-loc  and  Supervisor  as  well  as  Search)  to 
new  sonarmen,  they  [the  operator-trainees]  will  need  a  better  under¬ 
standing  of  sonar  principles  and  fire  control  principles  than  they  are 
new  being  given  in  basic  sonar  school." 

3.  Were  any  of  the  VAB  labels  unintelligible?  "No,  not  once  the  abbreviations 
[in  the  NSMRL  simulation]  were  explained. " 

3a.  Could  any  labels  be  improved?  "On  the  Class-Analysis  display,  change 
"release  signature  assembly"  to  "signature  assembly  completed"  [this  S 
was  hesitant  in  choosing  this  VAB  even  after  4  days]. 

4.  Were  any  functions  awkwardly  implemented?  "Nothing  that  really  sticks 
in  ray  mind .  " 

4a.  How  would  you  streamline  these  functions?  "In  Class-Analysis,  a  VAB  to 
jump  to  Class-Menu  directly  Lto  either  replace  C-A  or  put  C-M  on  the 
other  screen]  so  you  could  enter  classification  data  without  having  to 
go  through  "display  select"  [and  a  corresponding  VAB  on  C~M  to  return 
to  C-a] . 

4b.  Response  to  query  about  the  advisability  of  putting  ranging  and  CMA  access 
on  the  C-A  display.  "It's  helpful  to  have  it  in  C-A  [then]  it's  all  at 
your  f ingertips . " 

5.  What  current  equipment  performs  these  functions?  Skipped  this  question. 

6 .  Are  any  of  the  controls  improperly  grouped  together?  No . 

7.  Was  the  display  layout  adequate?  [the  use  of  schematic  displays  in  the 
NSMRL  simulation  doesn’t  allow  proper  evaluation  of  this  question.] 
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8. 


Did  the  arrangement  of  the  controls  ever  suggest  an  analysis?  "Yes  -  we 
don't  currently  do  ranging  -  seeing  'localization/range  history'  VAB 
reminds  you  [to  do  it] . " 

9.  Would  you  lay  out  any  display  differently?  "Yes.  In  the  Contact  Status 
log  section,  the  Sierra  number  should  be  on  the  left,  not  the  file 
number,  and  the  tracker  table  should  list  Sierra  numbers  instead  of  the 
file  numbers  [to  which  the  tracker  is  assigned]."  [using  the  present 
log  to  find  which  trackers  are  assigned  to  a  contact.-  requires  the  operator 
to  find  the  file  number,  which  he  doesn't  care  about.]  "Also,  the 
Contact  Status  Display  should  be  visible  all  the  time  -  maybe  a 
separate  repeater  for  this,  visible  from  all  3  consoles." 


Subject  F,  STS2 (SS)  (before  protocol) 

"It  wasn't  hard  at  all  -  I  had  no  major  complications  in  learning  the 
machine  -  being  a  sonar  tech  who  knows  his  job,  it's  relatively  easy  to 
follow  the  functions  on  the  machine  -  hard  to  switch  from  one  function  to 
another  -  but  that's  not  too  difficult  -  just  a  matter  of  practice." 

o  [Performance]-  Depends  on  how  well  he  knows  his  job,  not  how  well 
he  knows  the  machine  -  if  he  knows  his  job,  he  can  use  the  machine  with 
little  or  no  difficulty;  he'll  be  OK  if  he  knows  sonar.  Sonar  is  learned 
at  sea,  by  experience. 

Q:  Do  you  think  ISPE  will  help  to  learn  sonar? 

A:  Yes.  Signature  assembly  may  help  to  learn  contacts  of  interest; 

assigning  things  helps  to  understand  what  each  feature  does  for  you. 

o  "Button  Tree"  easy  -  for  a  person  who  does  know  his  job,  say  a  Chief, 
he'll  be  able  to  operate  the  system  with  little  practice. 

o  Subject  has  had  familiarization  with  the  AN/BQQ-5 ,  but  has  no 
feeling  for  the  difference  between  the  Q-5  and  ISPE. 

o  A  third  class  just  out  of  school  -  he  might  have  trouble  unless 
taught  features. 

Q:  Could  you  learn  the  machine  without  learning  a  little  bit  of  sonar  in  the 
process? 

A:  To  learn  the  machine  you  would  learn  a  bit  of  sonar. 

o  The  more  you  know  about  the  machine ,  the  more  you  have  to  learn 
about  sonar. 

o  Could  do  away  with  "search  mode"  altogether,  or  for  that  matter  with 
the  "Supervisor",  too.  Just  have  one  (each)  console  (that)  will  do  the 
whole  thing.. 
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NOTE;  Subject  not  qualified  as  supervisor. 

Subject  G f  STS2 (SS)  (before  protocol) 

1.  FABs  for  display  select  would  be  quicker  than  FAB-VAB  combination. 

2.  Set  up  Contact  Status  so  trackers  to  be  released  can  be  selected  with 
the  index  cursor  vice  "tracker  #"  VAB  requiring  keypad  entry. 

3.  Problem  trying  to  prosecute  one  contact  when  hooked  to  another:  on 
search  console,  perhaps  use  "complete  processing"  if  try  to  use  display 
other  than  the  one  through  which  hooked  (e.g.,  error  cue  if  push  VAB 

on  DLS  when  hooked  through  BBS) . 

Final  Comments: 

1.  Hooked  concept  a  minor  problem,  still  not  certain  what  the  point  of 
hooking  is. 

2.  Classification  functions  (complicated) ,  will  take  longer  to  learn. 

3.  The  system  is  complicated,  but  probably  not  difficult  to  operate. 

4.  Re  CONN  Display: 

a.  "as  long  as  he  (CONN)  gets  the  information  without  us  having  to 
tell  him,  that's  fine  with  me." 

b.  If  OOD  is  to  have  one  of  these,  he's  got  to  know  how  to  operate  it  - 

a  hassle,  and  can  interfere  if  sonar  techs  have  to  go  out  and  run  it  for  them, 
especially  in  heavy  situations. 

Subject  H,  STS2(SS)  (before  protocol) 

(Our  notes  on  this  debriefing  were  very  sketchy) 

1.  I  feel  that  the  search  operator  would  have  more  to  do  that  would  require 
some  sort  of  formal  training  before  he  should  be  allowed  on  the  stack. 

2.  I  also  feel  that  a  more  realistic  replica  of  the  ISPE  is  needed. 

3.  How  big  are  the  system's  CRTs?  X-ray  protection,  (?) 

4.  Re  data  on  screen: 

a.  There  might  be  too  many  different  kinds  of  info  on  CRT  at  one  time. 

b.  Wouldn't  be  possible  to  "window"  displays  so  that  you  could  look  more 
closely  at  a  selected  sub-display. 


c.  Still  feel  you  could  lose  the  picture.  While  telling  the  supervisor 
about  what  you  have,  you  could  lose  track  of  what  is  happening  in  all  the 
displays. 

5.  RLT  for  MTB  analog  tracker,  {subject  mistaken:  BDI  meter  provided  for 
MTB.] 

6.  I  suggest  a  separate  joystick  for  audio,  so  that  you  could  scan  continuously 
on  that. 


C-10 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (Whan  Data  Entered) 


REPORT  DOCUMENTATION  PAGE 

READ  INSTRUCTIONS 

BEFORE  COMPLETING  FORM 

1.  REPORT  NUMBER  2.  GOVT  ACCESSION  NO. 

NSMRL  Reoort  #951 

3.  RECIPIENT’S  CATALOG  NUMBER 

4.  TITLE  (and  Subtitle) 

OPERABILITY  EVALUATION  OF  THE  ISPE  CONTROL 
STRUCTURE 

5.  TYPE  OF  REPORT  ft  PERIOD  COVERED 

Interim  report 

6.  PERFORMING  ORG.  REPORT  NUMBER 

NSMRL  Report  No.  951 

7.  AUTHOR(a) 

Arthur  N.  BEARE  and  George  MOELLER 

8.  CONTRACT  OR  GRANT  NUMBERff) 

9.  PERFORMING  ORGANIZATION  NAME  AND  ADDRESS 

Naval  Submarine  Medical  Research  Laboratory 

Box  900,  Naval  Submarine  Base  New  London 

Groton  r  Connecticut.  05.149 

10.  PROGRAM  ELEMENT.  PROJECT,  TASK 
AREA  ft  WORK  UNIT  NUMBERS 

M0100PN.  001-1009 

1  1.  CONTROLLING  OFFICE  NAME  AND  ADDRESS 

Naval  Medical  Research  &  Development  Command 
National  Naval  Medical  Center 

Rethe  _ M^rvl  a  nd 9001  fl _ 

12.  REPORT  DATE 

12  Mav  1981 

13.  NUMBER  OF  PAGES 

mmmmm 

IS.  SECURITY  CLASS,  (of  thle  report) 

Unclassified 

15a.  DECLASSIFICATION/ DOWN  GRADING 
SCHEDULE 

16.  DISTRIBUTION  STATEMENT  (of  thte  Report) 

Approved  for  public  release;  distribution  unlimited 

17.  DISTRIBUTION  STATEMENT  (of  the  ebetraet  entered  In  Slock  30,  It  different  from  Report) 

is.  supplementary  notes 


19.  KEY  WORDS  (Continue  on  revetee  aide  it  necaaeary  and  Identity  by  block  number) 

Submarine  sonar  systems;  sonar  operators 


20.  ABSTRACT  (Coniinu*  on  revere*  uldm  It  n«c eeemry  mnd  identity  by  block  numborj 

Eight  experienced  FBM  sonar  operators  participated  in  an  evaluation  of  the 
"operability11  of  the  multifunction  switching  system  employed  for  system  control 
and  data  entry  in  the  ISPE  submarine  sonar  system.  Operability  was 
operationally  defined  in  terms  of  the  availability  of  controls  for  desired 
functions  and  the  number  and  kinds  of  errors  associated  with  control  usage. 
Experienced  FBM  sonarmen  were  individually  instructed  in  system  operation  for 
three  days  which  were  followed  by  two  days  of  testing  in  which  they  employed 


DD 


FORM 
1  JAN  73 


1473  EDITION  OF  1  NOV  68  IS  OBSOLETE 

S/N  0102*014*  6601  | 


Unclassified 


SECURITY  CLASSIFICATION  OF  THIS  PAGE  (Whan  Data  Entered) 


UNCLASSIFIED _ 

.LUJUITY  CLASSIFICATION  OF  THIS  PAGEfWTian  Data  Entered) _ _ 

Item  No.  20- continued 

the  simulated  system  in  two  mul ti -contact  scenarios. 

The  analysis  was  confined  to  controls  associated  with  displays  available 
in  the  search  and  class-loc  configurations.  All  functions  desired  by  the 
operators  were  readily  accessible.  Analysis  of  errors  revealed  that  it  is 
very  easy  to  misfile  information  or  assign  resources  to  the  wrong  contact. 
There  were  a  number  of  errors  traceable  to  control  labels  that  were  not  as 
informative  as  they  might  be,  and  one  instance  in  which  the  same  label  was 
used  for  controls  having  different  functions.  There  were  three  instances  in 
which  limitation  of  access  to  controls  when  in  the  "hooked"  mode  appeared  to 
be  counterproductive.  It  was  suggested  that  the  sonar  threat  acknowledgement 
functions  be  made  more  flexible. 

The  overall  operability  of  those  parts  of  the  control  structure  tested  was 
judged  to  be  very  good,  and  the  operation  of  the  system  appeared  to  be  very 
easy  to  learn  for  men  familiar  with  the  principles  of  sonar. 


UNCLASSIFIED 


5FDII*ITV  CLASSIFICATION  OF  THIS  P  ACEOWltn  Data  Enta  tad) 


